9ca435893b
make a series of modifications to the credential arguments relating to file read and write operations to cliarfy which credential is used for what: - Change fo_read() and fo_write() to accept "active_cred" instead of "cred", and change the semantics of consumers of fo_read() and fo_write() to pass the active credential of the thread requesting an operation rather than the cached file cred. The cached file cred is still available in fo_read() and fo_write() consumers via fp->f_cred. These changes largely in sys_generic.c. For each implementation of fo_read() and fo_write(), update cred usage to reflect this change and maintain current semantics: - badfo_readwrite() unchanged - kqueue_read/write() unchanged pipe_read/write() now authorize MAC using active_cred rather than td->td_ucred - soo_read/write() unchanged - vn_read/write() now authorize MAC using active_cred but VOP_READ/WRITE() with fp->f_cred Modify vn_rdwr() to accept two credential arguments instead of a single credential: active_cred and file_cred. Use active_cred for MAC authorization, and select a credential for use in VOP_READ/WRITE() based on whether file_cred is NULL or not. If file_cred is provided, authorize the VOP using that cred, otherwise the active credential, matching current semantics. Modify current vn_rdwr() consumers to pass a file_cred if used in the context of a struct file, and to always pass active_cred. When vn_rdwr() is used without a file_cred, pass NOCRED. These changes should maintain current semantics for read/write, but avoid a redundant passing of fp->f_cred, as well as making it more clear what the origin of each credential is in file descriptor read/write operations. Follow-up commits will make similar changes to other file descriptor operations, and modify the MAC framework to pass both credentials to MAC policy modules so they can implement either semantic for revocation. Obtained from: TrustedBSD Project Sponsored by: DARPA, NAI Labs |
||
---|---|---|
.. | ||
acl.h | ||
dinode.h | ||
dir.h | ||
dirhash.h | ||
extattr.h | ||
inode.h | ||
quota.h | ||
README.acls | ||
README.extattr | ||
ufs_acl.c | ||
ufs_bmap.c | ||
ufs_dirhash.c | ||
ufs_extattr.c | ||
ufs_extern.h | ||
ufs_ihash.c | ||
ufs_inode.c | ||
ufs_lookup.c | ||
ufs_quota.c | ||
ufs_vfsops.c | ||
ufs_vnops.c | ||
ufsmount.h |
$FreeBSD$ UFS Extended Attributes Copyright The UFS Extended Attributes implementation is copyright Robert Watson, and is made available under a Berkeley-style license. About UFS Extended Attributes Extended attributes allow the association of additional arbitrary meta-data with files and directories. Extended attributes are defined in the form name=value, where name is an nul-terminated string in the style of a filename, and value is a binary blob of zero or more bytes. The UFS extended attribute service layers support for extended attributes onto a backing file, in the style of the quota implementation, meaning that it requires no underlying format changes in the filesystem. This design choice exchanges simplicity, usability and easy deployment for performance. When defined, extended attribute names exist in a series of disjoint namespaces: currently, two namespaces are defined: EXTATTR_NAMESPACE_SYSTEM and EXTATTR_NAMESPACE_USER. The primary distinction lies in the protection model: USER EAs are protected using the normal inode protections, whereas SYSTEM EAs require privilege to access or modify. Using UFS Extended Attributes Support for UFS extended attributes may be enabled by adding: options UFS_EXTATTR to your kernel configuration file. This allows UFS-based filesystems to support extended attributes, but requires manual administration of EAs using the extattrctl tool, including the starting of EA support for each filesystem, and the enabling of individual attributes for the file system. The extattrctl utility may be used to initialize backing files before first use, to start and stop EA service on a filesystem, and to enable and disable named attributes. The command lines for extattrctl take the following forms: extattrctl start [path] extattrctl stop [path] extattrctl initattr [-f] [-p path] [attrsize] [attrfile] extattrctl enable [path] [attrnamespace] [attrname] [attrfile] extattrctl disable [path] [attrnamespace] [attrname] In each case, [path] is used to indicate the mounted filesystem on which to perform the operation. [attrnamespace] refers to the namespace in which the attribute is being manipulated, and may be "system" or "user". The [attrname] is the attribute name to use for the operation. The [attrfile] argument specifies the attribute backing file to use. When using the "initattr" function to initialize a backing file, the maximum size of attribute data must be defined in bytes using the [attrsize] field. Optionally, the [-p path] argument may be used to indicate to extattrctl that it should pre-allocate space for EA data, rather than creating a sparse backing file. This prevents attribute operations from failing in low disk-space conditions (which can be important when EAs are used for security purposes), but pre-allocation will consume space proportional to the product of the defined maximum attribute size and number of attributes on the specified filesystem. Manual configuration increases administrative overhead, but also introduces the possibility of race conditions during filesystem mount, if EAs are used to support other features, as starting the EAs manually is not atomic with the mount operation. To address this problem, an additional kernel option may be defined to auto-start EAs on a UFS file system based on special directories at mount-time: options UFS_EXTATTR_AUTOSTART If this option is defined, UFS will search for a ".attribute" sub-directory of the filesystem root during the mount operation. If it is found, EA support will be started for the filesystem. UFS will then search for "system" and "user" sub-directories of the ".attribute" directory for any potential backing files, and enable an EA for each valid backing file with the name of the backing file as the attribute name. For example, by creating the following tree, the two EAs, posix1e.acl_access and posix1e.acl_default will be enabled in the system namespace of the root filesystem, reserving space for attribute data: mkdir -p /.attribute/system cd /.attribute/system extattrctl initattr -p / 388 posix1e.acl_access extattrctl initattr -p / 388 posix1e.acl_default On the next mount of the root filesystem, the attributes will be automatically started.