Making files on ZFS Immutable (even by root!)

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 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.

Comments:

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

Posted by UX-admin on August 14, 2008 at 08:48 AM BST #

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.

Posted by Darren Moffat on August 14, 2008 at 09:02 AM BST #

Can you outline the reasoning behind adding this functionality?

Also, this seems to be highly correlated with the "flags" found in BSD:

http://www.freebsd.org/cgi/man.cgi?query=chflags&sektion=1
http://www.freebsd.org/cgi/man.cgi?query=chflags&sektion=2

Coincidence?

Posted by David Magda on August 14, 2008 at 05:35 PM BST #

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.

Posted by UX-admin on August 15, 2008 at 03:21 AM BST #

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.

Posted by Darren Moffat on August 15, 2008 at 03:35 AM BST #

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.

Posted by Darren Moffat on August 15, 2008 at 03:37 AM BST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

DarrenMoffat

Search

Categories
Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today