Messages in this thread | | | Date | Tue, 15 Feb 2000 07:54:15 -0600 (CST) | From | Jesse Pollard <> | Subject | Re: Capabilities |
| |
jmcmullan@linuxcare.com ... ># cat /proc/sys/fs/caps/summary >id usage name capability >0 35 default 0x00000000000000FF >1 47 root 0x000007F007FFFFFF >2 2 http 0x0000000007F87601 >5 5 ftp 0x00000000000005FF >6 0 squid 0x00000F0000FF08FF
Actually, 0 would have no capabilities - why give capabilities to a data file? This makes the table:
id usage name capability 1 35 default 0x00000000000000FF 2 47 root 0x000007F007FFFFFF 3 2 http 0x0000000007F87601 6 5 ftp 0x00000000000005FF 7 0 squid 0x00000F0000FF08FF ... > Ah - NOW you see where this scheme runs into trouble: > > a) How can I, as a process, drop a single capability from > my capability mask AND have it reported? /proc/self/caps?
The capability list of a process (active object) does not have to match the initial capability list of a file (passive object). Once the process is active (with the initial capability list from the passive inode) the process can (should) always drop capabilities as desired.
It just can't (should not) be able to gain capabilities - or you get into the "setpriv" problem that the old vax VMS system had ("I only need one privilege ...").
If the active capability list of a process need to be visible, then a proc/self/caps would be reasonable (as well as proc/<pid>/caps). It should also be recorded in an audit log and/or accounting log.
> b) Since (correct me if I'm wrong) inodes are cached from disk, > doesn't this mean that we only get a summary of _CURRENTLY_CACHED_ > inodes? If so, do we really get an accounting advantage over the > bitmask per inode scheme?
The summary (as shown from the table) would be system wide global. The biggest threat comes from mounting filesystems - If a filesystem is initialized on one system with a set of capability identifiers, and later mounted on a different system - with a different set of identifiers, then the files residing on the filesystem will gain/lose some arbitrary set of capabilities.
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).
The actual inode caching only provides immediate access to the capability identifier - which would NOT be used by the active object (the process that may be associated with the inode). ------------------------------------------------------------------------- Jesse I Pollard, II Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
- 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/
| |