Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil> wrote:
> The capability list table should be stored in/with the superblock,
> and the active list is formed by concatenating the list of all mounted
> file systems. This implies that s lookup of a capability identifier
> includes the mount device. It would even allow for the capability identifier
> table to exist as a reserved inode, that could be independantly edited,
> and loaded into the kernel on mount. Having the capability table on the
> same file system would make the reference count cumulative
> and accurate (as well as fixable by fsck).
So let me see play with something here (and add the concept
of a ``Features'' inode, so that we don't have to eat up
any more space in the superblock):
/dev/hda1 (ext4fs)
Superblock: Pointer to ``features'' inode
Features Inode:
Pointer to Capabilities Inode
Pointer to ACL Inode
Pointer to Data Log
Pointer to Metadata Log
...
Capability List: (id,capability,usage_count) tuples
Arbitrary Inode: inode->i_capability = pointer to capability id
So when I mount /dev/hda1, /proc/sys/caps/summary contains
the UNION of all the filesystems' capabilities, right? The kernel
could get this information directly from the Capability List inode.
$ cat /proc/sys/caps/03:01
id capability usage
1 0x002F 454
2 0x00FF 67
...
$ cat /proc/sys/caps/summary
device id capability usage
03:01 1 0x002F 454
03:01 2 0x00FF 67
...
08:03 1 0x00F2 36
08:03 4 0xFF00 76
..
And also, I would see under /proc/{[0-9]*,self}/caps the
_current_ capability mask for a process? Right?
Now, if I were to change the capability id for an inode:
$ chcap --capability=2 /etc/passwd
Then, it would be reflected in the Capability list inode on /dev/hda1.
(which would be preserved on umount)
Sounds like an excellent approach.
-- Jason McMullan, Senior Linux Consultant, Linuxcare, Inc. 412.422.8077 tel, 415.701.0792 fax jmcmullan@linuxcare.com, http://www.linuxcare.com/ Linuxcare. Support for the revolution.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:29 EST