Thursday August 14, 2008
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.txtOr 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.
( Aug 14 2008, 01:24:53 PM BST ) Permalink Comments [6]Heaps of info available on files via good old ls(1) [ But not encryption status ]
In "compact" form:
ls -V@ -/c -% all /tank/fs/hamlet.txt
-rw-r--r--+ 1 root root 211179 Aug 14 12:20 /tank/fs/hamlet.txt
{AHRSa-i--u}
timestamp: atime Aug 14 12:37:37 2008
timestamp: ctime Aug 14 12:32:58 2008
timestamp: mtime Aug 14 12:20:08 2008
timestamp: crtime Aug 14 12:19:41 2008
user:lp:r-------------:-------:deny
owner@:--x-----------:-------:deny
owner@:rw-p---A-W-Co-:-------:allow
group@:-wxp----------:-------:deny
group@:r-------------:-------:allow
everyone@:-wxp---A-W-Co-:-------:deny
everyone@:r-----a-R-c--s:-------:allow
In verbose form:
ls -v@ -/v -% all /tank/fs/hamlet.txt
-rw-r--r--+ 1 root root 211179 Aug 14 12:20 /tank/fs/hamlet.txt
{archive,hidden,readonly,system,appendonly,nonodump,
immutable,noav_modified,noav_quarantined,nounlink}
timestamp: atime Aug 14 12:21:12 2008
timestamp: ctime Aug 14 12:32:58 2008
timestamp: mtime Aug 14 12:20:08 2008
timestamp: crtime Aug 14 12:19:41 2008
0:user:lp:read_data:deny
1:owner@:execute:deny
2:owner@:read_data/write_data/append_data/write_xattr/write_attributes
/write_acl/write_owner:allow
3:group@:write_data/append_data/execute:deny
4:group@:read_data:allow
5:everyone@:write_data/append_data/write_xattr/execute/write_attributes
/write_acl/write_owner:deny
6:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
:allow
One interesting thing it doesn't tell me about this file is that it is that all that information is encrypted on disk. For that I have to use zfs(1):
# zfs get encryption tank/fs NAME PROPERTY VALUE SOURCE tank/fs encryption on local
Or a little more verbosely:
# zfs list -r -o name,encryption,keyscope,keystatus,mounted tank NAME CRYPT KEYSCOPE KEYSTATUS MOUNTED tank off pool undefined yes tank/fs on pool available yes
I wonder if it is worth having the verbose ls(1) output indicate that the file was encrypted on "disk" by the filesystem.
What would people do with that info if they had it ? Any ideas let me know.
( Aug 14 2008, 12:49:15 PM BST ) Permalink Comments [2]
This is a personal weblog, I do not speak for my employer.
