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/
This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:29 EST