> Well, you're right as it currently stands. The problem is those UID
> 'compatibility mode' options were meant to hold us over until the
> filesystems could support capabilities,
They are not just to "hold us over". The traditional system must
continue to work, because many people will not want to change.
> which spawned an entire OTHER
> argument on how that should be done. (ext2+caps,elfcap,et al)
Yep. Capabilities in ext2 is just wrong. Using ELF is merely bad.
This is a UNIX clone you know; you can't make it into VMS.
> As far as I can see,
> interest in capabilities is limited to myself, and Mark Heuse
> (compartment for SuSE). I haven't seen much else development
> in programs to use capabilities in the past year.
Ever wonder why? The system is not compatible with UNIX.
It isn't even safe. This is making MAC look easy, since at
least MAC operates "outside" the normal security system.
> Personally, I have working 'capabilities-smart' bind-8.1.2
> chroot, ping and traceroute, apache, and
> pidentd. I've used compartment to jail mysql with no caps.
Meanwhile, Theodore T'so and the SGI people are considering
a change to the basic algorithms. Are you sure you want to
rely on this stuff?
> All I can do at this point is make sure what's there now
> isn't broken to save some other functionality problem.
What's there now is already broken. As I wrote above, there
might be some major changes in the future. By that I mean the
basic inheritance algorithm could go from draft 17 to draft 16.
I think it is long past time to admit the mistake and start over.
That is, rip out the system calls and rethink the design.
Sorry about your daemons... but the conversion to draft 16
would break them anyway.
I know one way to fix all this. It is not nearly as fancy, but at
least it doesn't cause so many incompatibilities. Do the obvious.
Have UID-to-capability and GID-to-capability tables in the kernel.
Load them early in the boot or via a trusted daemon. This doesn't
have any "way cool" inheritance algorithms to confuse admins and
programs alike. It just works. Across an exec, capabilities must
be fully enabled for compatibility. Capability-aware programs
could disable unneeded privilege as the first step in main.
Anyway, for now the code should just be removed.
-
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 : Thu Jun 15 2000 - 21:00:24 EST