Re: Capabilities

Jesse Pollard <[e-mail]> 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
[e-mail], http://www.linuxcare.com/
Linuxcare. Support for the revolution.