Zfs: File Attributes

I think it is worthwhile to support the standard Linux attributes like immutable, append-only, etc in the FS_*_FL space, even if you later decide to import the Solaris tool for the same. Many different filesystems on Linux support the lsattr/chattr ioctl() interface for setting these flags, though some filesystems translate the flags to (nearly) equivalent on-disk values for their own use.

It isn't impossible to add new attributes to FS_*_FL if they are generally useful (I don't know what attributes Solaris has that Linux does not), though that space is running out so they can't be added willy-nilly.

I agree, a few months back I made an initial foray in to attempting to support the standard Linux attributes. I determined at the time that immutable, append-only, and nodump were the only attributes common between Solaris and Linux. Unfortunately, I wasn't able to find the time to finish this work but the development branch is available. Below is the full list of zfs attributes just for reference.

/*
 * Additional file level attributes, that are stored
 * in the upper half of zp_flags
 */
#define ZFS_READONLY            0x0000000100000000ull
#define ZFS_HIDDEN              0x0000000200000000ull
#define ZFS_SYSTEM              0x0000000400000000ull
#define ZFS_ARCHIVE             0x0000000800000000ull
#define ZFS_IMMUTABLE           0x0000001000000000ull
#define ZFS_NOUNLINK            0x0000002000000000ull
#define ZFS_APPENDONLY          0x0000004000000000ull
#define ZFS_NODUMP              0x0000008000000000ull
#define ZFS_OPAQUE              0x0000010000000000ull
#define ZFS_AV_QUARANTINED      0x0000020000000000ull
#define ZFS_AV_MODIFIED         0x0000040000000000ull
#define ZFS_REPARSE             0x0000080000000000ull
#define ZFS_OFFLINE             0x0000100000000000ull
#define ZFS_SPARSE              0x0000200000000000ull

As I mentioned on the mailing list, I looked into this, and thought about the mappings. Here are my thoughts for others to consider as much or as little as they see fit:

Obvious mappings:
ZFS_IMMUTABLE <-> FS_IMMUTABLE_FL
ZFS_APPENDONLY <-> FS_APPEND_FL
ZFS_NODUMP <-> FS_NODUMP_FL

Possibly a good idea for compatibility reasons:
If ZFS_IMMUTABLE is ever set, clear ZFS_NOUNLINK. This would allow a user to clear ZFS_NOUNLINK with: chattr +i FILE ; chattr -i FILE

Crazy idea 1:
Map ZFS_READONLY, ZFS_HIDDEN, ZFS_SYSTEM, and ZFS_ARCHIVE and the crtime to a Samba-compatible user.DOSATTRIB xattr.

Crazy idea 2:
Setting FS_TOPDIR_FL on a directory sets a property so that mkdir() operations in that directory create new ZFS datasets. This would be useful for /home, for example. Then you don't need to hook ZFS changes into useradd on Linux. And it's a reasonable idea to chattr +T /home on ext[234] already. Even if you don't hook FS_TOPDIR_FL to it, the idea of a ZFS property to this effect would still be useful on /home.

Hello,

is there any progress on this topic? I recently switched my media server to ZFS but I miss the possibility to set the immutable flag. I would like to "protect" some files, is there any workaround to set the flag? Maybe via an external program? Would this work?

Thank you!

@cyberius0 Nobody is currently working on this. But if someone would like to I'm all for it.

id like to give it a shot if someone would point me in the right direction. I need this feature.

+1

@rlaager 's Crazy idea 2 sounds immensely useful. I'd like to request that that become a thing.

+1

It should be noted that the Linux file attribute interface suffers from a TOCTOU race that does not occur on Solaris. The userland tools on both Solaris and Linux take modifications to the file attributes as arguments and the file attributes are stored in-core and on-disk as bit masks, but the similarities end there.

On Solaris, a list of which values will change, accompanied by what their values will be, is sent to the kernel. The act of taking the current bitmask, modifying it and storing it is then processed under zp->z_lock. This ensures that all changes are atomic, which is the right way to do things. On Linux, the responsibility for modifications is outsourced to userland. The userland utility will get the current bitmask, make the changes and send a new bitmask that replaces the old one. Since userland cannot lock the file against modifications, two concurrent threads touching different bits on the same file can be either both changes or only 1 change.

zfsonlinux/zfs#1693 made ZFSOnLinux vulnerable to this problem by implementing some translation code between the Linux interface and the ZFS interface from Solaris. Thankfully, such rapid modification of file attributes is rare, which is likely why this was not detected when file attributes were first implemented on Linux. We should deprecate the Linux interface in favor of an atomic interface along the lines of what Solaris does when we implement our own file attribute modification tools Those will be needed to expose the full range of ZFS file attributes that we inherited from Solaris.

Support for the obvious mappings has been merged and will be part of 0.6.3.

• ZFS_IMMUTABLE <-> FS_IMMUTABLE_FL
• ZFS_APPENDONLY <-> FS_APPEND_FL
• ZFS_NODUMP <-> FS_NODUMP_FL

This does not cover attributes which exist on Linux but not Illumos and vise-versa. Since we are going to have to handle those on a case-by-case I think it makes sense to close this issue. We can open a new issue for each attribute as needed to discuss the details of how it should behave.

9d31779 Implement File Attribute Support
3b4f425 Refactor inode_owner_or_capable() autotools check

@behlendorf Is there documentation or manual that lists which attributes are supported and what they do on a ZFS system?