Kenneth D. Merry 7da1a731c6 Expand the use of stat(2) flags to allow storing some Windows/DOS
and CIFS file attributes as BSD stat(2) flags.

This work is intended to be compatible with ZFS, the Solaris CIFS
server's interaction with ZFS, somewhat compatible with MacOS X,
and of course compatible with Windows.

The Windows attributes that are implemented were chosen based on
the attributes that ZFS already supports.

The summary of the flags is as follows:

UF_SYSTEM:	Command line name: "system" or "usystem"
		ZFS name: XAT_SYSTEM, ZFS_SYSTEM
		Windows: FILE_ATTRIBUTE_SYSTEM

		This flag means that the file is used by the
		operating system.  FreeBSD does not enforce any
		special handling when this flag is set.

UF_SPARSE:	Command line name: "sparse" or "usparse"
		ZFS name: XAT_SPARSE, ZFS_SPARSE
		Windows: FILE_ATTRIBUTE_SPARSE_FILE

		This flag means that the file is sparse.  Although
		ZFS may modify this in some situations, there is
		not generally any special handling for this flag.

UF_OFFLINE:	Command line name: "offline" or "uoffline"
		ZFS name: XAT_OFFLINE, ZFS_OFFLINE
		Windows: FILE_ATTRIBUTE_OFFLINE

		This flag means that the file has been moved to
		offline storage.  FreeBSD does not have any special
		handling for this flag.

UF_REPARSE:	Command line name: "reparse" or "ureparse"
		ZFS name: XAT_REPARSE, ZFS_REPARSE
		Windows: FILE_ATTRIBUTE_REPARSE_POINT

		This flag means that the file is a Windows reparse
		point.  ZFS has special handling code for reparse
		points, but we don't currently have the other
		supporting infrastructure for them.

UF_HIDDEN:	Command line name: "hidden" or "uhidden"
		ZFS name: XAT_HIDDEN, ZFS_HIDDEN
		Windows: FILE_ATTRIBUTE_HIDDEN

		This flag means that the file may be excluded from
		a directory listing if the application honors it.
		FreeBSD has no special handling for this flag.

		The name and bit definition for UF_HIDDEN are
		identical to the definition in MacOS X.

UF_READONLY:	Command line name: "urdonly", "rdonly", "readonly"
		ZFS name: XAT_READONLY, ZFS_READONLY
		Windows: FILE_ATTRIBUTE_READONLY

		This flag means that the file may not written or
		appended, but its attributes may be changed.

		ZFS currently enforces this flag, but Illumos
		developers have discussed disabling enforcement.

		The behavior of this flag is different than MacOS X.
		MacOS X uses UF_IMMUTABLE to represent the DOS
		readonly permission, but that flag has a stronger
		meaning than the semantics of DOS readonly permissions.

UF_ARCHIVE:	Command line name: "uarch", "uarchive"
		ZFS_NAME: XAT_ARCHIVE, ZFS_ARCHIVE
		Windows name: FILE_ATTRIBUTE_ARCHIVE

		The UF_ARCHIVED flag means that the file has changed and
		needs to be archived.  The meaning is same as
		the Windows FILE_ATTRIBUTE_ARCHIVE attribute, and
		the ZFS XAT_ARCHIVE and ZFS_ARCHIVE attribute.

		msdosfs and ZFS have special handling for this flag.
		i.e. they will set it when the file changes.

sys/param.h:		Bump __FreeBSD_version to 1000047 for the
			addition of new stat(2) flags.

chflags.1:		Document the new command line flag names
			(e.g. "system", "hidden") available to the
			user.

ls.1:			Reference chflags(1) for a list of file flags
			and their meanings.

strtofflags.c:		Implement the mapping between the new
			command line flag names and new stat(2)
			flags.

chflags.2:		Document all of the new stat(2) flags, and
			explain the intended behavior in a little
			more detail.  Explain how they map to
			Windows file attributes.

			Different filesystems behave differently
			with respect to flags, so warn the
			application developer to take care when
			using them.

zfs_vnops.c:		Add support for getting and setting the
			UF_ARCHIVE, UF_READONLY, UF_SYSTEM, UF_HIDDEN,
			UF_REPARSE, UF_OFFLINE, and UF_SPARSE flags.

			All of these flags are implemented using
			attributes that ZFS already supports, so
			the on-disk format has not changed.

			ZFS currently doesn't allow setting the
			UF_REPARSE flag, and we don't really have
			the other infrastructure to support reparse
			points.

msdosfs_denode.c,
msdosfs_vnops.c:	Add support for getting and setting
			UF_HIDDEN, UF_SYSTEM and UF_READONLY
			in MSDOSFS.

			It supported SF_ARCHIVED, but this has been
			changed to be UF_ARCHIVE, which has the same
			semantics as the DOS archive attribute instead
			of inverse semantics like SF_ARCHIVED.

			After discussion with Bruce Evans, change
			several things in the msdosfs behavior:

			Use UF_READONLY to indicate whether a file
			is writeable instead of file permissions, but
			don't actually enforce it.

			Refuse to change attributes on the root
			directory, because it is special in FAT
			filesystems, but allow most other attribute
			changes on directories.

			Don't set the archive attribute on a directory
			when its modification time is updated.
			Windows and DOS don't set the archive attribute
			in that scenario, so we are now bug-for-bug
			compatible.

smbfs_node.c,
smbfs_vnops.c:		Add support for UF_HIDDEN, UF_SYSTEM,
			UF_READONLY and UF_ARCHIVE in SMBFS.

			This is similar to changes that Apple has
			made in their version of SMBFS (as of
			smb-583.8, posted on opensource.apple.com),
			but not quite the same.

			We map SMB_FA_READONLY to UF_READONLY,
			because UF_READONLY is intended to match
			the semantics of the DOS readonly flag.
			The MacOS X code maps both UF_IMMUTABLE
			and SF_IMMUTABLE to SMB_FA_READONLY, but
			the immutable flags have stronger meaning
			than the DOS readonly bit.

stat.h:			Add definitions for UF_SYSTEM, UF_SPARSE,
			UF_OFFLINE, UF_REPARSE, UF_ARCHIVE, UF_READONLY
			and UF_HIDDEN.

			The definition of UF_HIDDEN is the same as
			the MacOS X definition.

			Add commented-out definitions of
			UF_COMPRESSED and UF_TRACKED.  They are
			defined in MacOS X (as of 10.8.2), but we
			do not implement them (yet).

ufs_vnops.c:		Add support for getting and setting
			UF_ARCHIVE, UF_HIDDEN, UF_OFFLINE, UF_READONLY,
			UF_REPARSE, UF_SPARSE, and UF_SYSTEM in UFS.
			Alphabetize the flags that are supported.

			These new flags are only stored, UFS does
			not take any action if the flag is set.

Sponsored by:	Spectra Logic
Reviewed by:	bde (earlier version)
2013-08-21 23:04:48 +00:00
..
2012-04-23 17:54:49 +00:00

$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 is natively available in UFS2, and
requires no special configuration.  For reliability, administrative,
and performance reasons, if you plan to use extended attributes, it
is recommended that you use UFS2 in preference to UFS1.

Support for UFS extended attributes may be enabled for UFS1 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.