X

News, tips, partners, and perspectives for the Oracle Solaris operating system

Making files on ZFS Immutable (even by root!)

Darren Moffat
Senior Software Architect

First lets look at the normal POSIX file permissions and show who we are and
what privileges our shell is running with:

# ls -l /tank/fs/hamlet.txt 
-rw-rw-rw-   1 root     root      211179 Aug 14 13:00 /tank/fs/hamlet.txt
# pcred $$
100618: e/r/suid=0  e/r/sgid=0
        groups: 0 1 2 3 4 5 6 7 8 9 12
# ppriv $$
100618: -zsh
flags = 
        E: all
        I: all
        P: all
        L: all

So we are running as root and have all privileges in our process and are
passing all on to our children. We also own the file (and it is on a local ZFS filesystem not over NFS), and it is writable by us and our group, everyone in fact.
So lets try and modify it:

# echo "SCRIBBLE" > /tank/fs/hamlet.txt 
zsh: not owner: /tank/fs/hamlet.txt

That didn't work lets try and delete it, but first check the permissions of
the containing directory:

# ls -ld /tank/fs
drwxr-xr-x   2 root     root           3 Aug 14 13:00 /tank/fs
# rm /tank/fs/hamlet.txt
rm: /tank/fs/hamlet.txt: override protection 666 (yes/no)? y
rm: /tank/fs/hamlet.txt not removed: Not owner

That is very strange, so what is going on here ?

Before I started this I made the file immutable. That means that regardless
of what privileges(5) the process has and what POSIX permissions or NFSv4/ZFS ACL
it has we can't delete it change it nor can we even change the POSIX permissions
or the ACL. So how did we do that ? Without good old friend chmod:

# chmod S+ci /tank/fs/hamlet.txt

Or more verbosely:
# chmod S+v immutable /tank/fs/hamlet.txt

See chmod(1) for more details. For those of you running OpenSolaris 2008.05 releases then you need to change the default PATH to have /usr/bin in front of /usr/gnu/bin or use the full path to /usr/bin/chmod. This is because these extensions are only part of the OpenSolaris chmod command not the GNU version. The same applies to my previous posting on the extended output from ls.

Join the discussion

Comments ( 6 )
  • UX-admin Thursday, August 14, 2008

    Did someone just break the whole UNIX / root concept by messing with chmod(1)?


  • Darren Moffat Thursday, August 14, 2008

    In response to UX-admin. No they didn't the extensions are completely compatible. This doesn't break or change any of the traditional UNIX permissions syntax for chmod(1) and you aren't forced to use any of the new stuff.


  • UX-admin Friday, August 15, 2008

    Why was it put in there?

    Why doesn't it let root override it?

    How can it be set back once it is made immutable?

    The man pages don't say that much about it.


  • Darren Moffat Friday, August 15, 2008

    David: No on Coincidence at all it is intended to provide the matching functionality to BSD. There are other system flags that were added to support CIFS (SMB), such as Archive, System, Hidden, AntiVirus.


  • Darren Moffat Friday, August 15, 2008

    UX-admin: It doesn't let root override it because that is the whole point of it. It can be turned off by doing 'chmod S-v file' then root can do what it can normally do to the file. Note that immutable isn't the only flag we have there are others, some for CIFS and some others to match what BSD and Linux already had.


  • DavidH Wednesday, March 27, 2019
    Was the verbose command line supposed to duplicate chmod?

    i.e.
    # chmod chmod S+v immutable /tank/fs/hamlet.txt
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.