setflabel - change effective sensitivity label of a file
cc [flag...] file... -ltsol [library...]
#include <tsol/label.h> int setflabel(const char *path, const m_label_t *label_p);
In most cases, the file that is named by path is relabeled by moving it to a new pathname relative to the root directory of the zone corresponding to label_p. If the source and destination file systems are loopback mounted from the same underlying file system, the file is renamed. Otherwise, the file is copied and removed from the source directory.
However, setflabel() behaves differently for files and directories which are on multilevel ZFS file systems. Refer to zfs(1M). In that case, files are not moved, but are relabeled in place, since multilevel file systems support per-file labels.
The setflabel() function enforces the following policy checks:
Files and directories on multilevel file systems are relabeled in place; they are not moved, and the relabel script described below does not apply to them.
For multilevel file systems, the label of a directory cannot be changed if the directory is not empty. The new label for an object must dominate the label of its parent directory. If the new label does not match the label of the parent directory, the caller must have the PRIV_FILE_UPGRADE_SL privilege. The new label must be dominated by the mlslabel property of the file system. If the caller is not in the global zone, the zone label must dominate the new label.
The remaining policy checks below apply to multilevel file systems as well, except where otherwise noted.
If the sensitivity label of label_p equals the existing sensitivity label, then the file is not affected.
If the corresponding directory does not exist in the destination zone, or if the directory exists, but has a different label than label_p, the file is not moved. Also, if the file already exists in the destination directory, the file is not moved. This does not apply to multilevel file systems.
If the sensitivity label of the existing file is not equal to the calling process label and the caller is not in the global zone, then the file is not affected. If the caller is in the global zone and the file in not on a multilevel file systems, the existing file label must be in a labeled zone (not ADMIN_LOW or ADMIN_HIGH).
If the calling process does not have write access to both the source and destination directories, then the calling process must have PRIV_FILE_DAC_WRITE in its set of effective privileges.
If the sensitivity label of label_p provides read only access to the existing sensitivity label (an upgrade), then the user must have the solaris.label.file.upgrade authorization. In addition, if the current zone is a labeled zone, then it must have been assigned the privilege PRIV_FILE_UPGRADE_SL when the zone was configured.
If the sensitivity label of label_p does not provide access to the existing sensitivity label (a downgrade), then the calling user must have the solaris.label.file.downgrade authorization. In addition, if the current zone is a labeled zone, then it must have been assigned the privilege PRIV_FILE_DOWNGRADE_SL when the zone was configured.
If the calling process is not in the global zone, and the user does not have the solaris.label.range authorization, then label_p must be within the user's label range and within the system accreditation range.
If the existing file is in use (not tranquil) it is not affected. This tranquility check does not cover race conditions nor remote file access.
Additional policy constraints can be implemented by customizing the shell script /etc/security/tsol/relabel. See the comments in this file. Note that this script does not apply to multilevel file systems.
Upon successful completion, setflabel() returns 0. Otherwise it returns -1 and sets errno to indicate the error.
The setflabel() function fails and the file is unchanged if:
Search permission is denied for a component of the path prefix of path.
The calling process does not have mandatory write access to the final component of path because the sensitivity label of the final component of path does not dominate the sensitivity label of the calling process and the calling process does not have PRIV_FILE_MAC_WRITE in its set of effective privileges.
There is an open file descriptor reference to the final component of path.
A connection to the label daemon could not be established.
A file with the same name exists in the destination directory.
Improper parameters were received by the label daemon.
For callers not in the global zone and when path is not on a multilevel ZFS file system, the specified label does not match the caller's label.
For multilevel ZFS file systems, the specified label is not dominated by all of the following: the file system MLSLABEL property, the label of the parent directory of path, and the caller's label.
The existing file is a directory.
Too many symbolic links were encountered in translating path.
The existing file is hardlinked to another file.
The length of the path argument exceeds PATH_MAX.
The file referred to by path does not exist.
The file system is read-only or its label is ADMIN_LOW or ADMIN_HIGH.
See attributes(5) for descriptions of the following attributes:
Setting a File Sensitivity Label in Trusted Extensions Developer’s Guide
The functionality described on this manual page is available only if the system is configured with Trusted Extensions.