[...]
> 1) 'setuid 0' is _just_ a filesystem flag that alerts the kernel to a
> program that has capabilities + uid + gid in the elf headers. (putting
> uid & gid in the headers was Albert's idea, and now seems to me a must)
Current tools won't recognize a file belonging to jschmoe as hers, quotas
will go haywire too.
[...]
> 5) when the kernel exec's an elf binary, the effect is exactly as in my
> previous itteration:
> - checks capability flag (setuid 0) and if set uses caps + uid + gid from
> elf headers
> - if calling process has no caps, process runs with no caps
> - if calling process has elevated caps, kernel applies the permittable and
> inheritable cap flags from the binary (which can only be modified by the
> owner in any event)
When old kernel executes program that has just the capability to bind to a
low port, it is now suddenly all-powerfull...
This kind of idea _mandates_ at _least_ a new executable format all
around. Remember the a.out --> ELF pain? The screwups libc5 --> libc6? And
all to ease/postpone the pain of introducing capabilities into the FS? No,
thanks.
> I _think_ this covers all the bases to give us a very flexible and
> UNIX-ish capability system for elf binaries, but I won't go as far as
> calling this a 'final' itteration yet. Add the notion of user cabilities
> granted by 'login' from /etc/shadow or wherever...
Any ACL system is inherently distinctly un-Unix-ish, IMHO. Better bite that
bullet once now and get it over with.
-- Horst von Brand vonbrand@sleipnir.valparaiso.cl Casilla 9G, Viņa del Mar, Chile +56 32 672616- 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/