Messages in this thread | | | Date | Sat, 18 Dec 1999 23:13:49 +0100 | From | Pavel Machek <> | Subject | Re: [RFC] Problem with Linux capabilities support |
| |
Hi!
> Earlier this week I posted about writing a program called > scap which would allow you allow users to access certain > capabilities. Little did I know that it would be impossible > at the current time. > > For a program like scap to give capabilities to normal users, > it would need to have the privalegdes to add bits to the > permitted set. At the moment this can only be done by marking > the executable setuid root or hacking it to get CAP_SETPCAP > priviledges and other rights. > > The problem is that this obliterates the previous capabilities > set. Once scap has started running, it no longer knows which > capabilites the user already had active. At the moment I get > around this by taking the capability set from the parent and > working from that. But that is bad.
fork() and then look at _your_ parent.
> The second problem is that if scap is run setuid, at some stage > it has to switch back to the previous uid, at which stage all > the capabilites are cleared and your work is undone. I know that
what about two programs, scap0 and scap. scap0 is setuid. scap execs scap0, scap0 looks at its capabilities, and raises them as needed, then scap0 dies...
> this is for compatability for userspace that does not know > about capabilities, but it makes it also somewhat useless until > the whole of userspace is ready. Surely we can do better than > that?
> The first thing that popped into my head was to define a > CAP_ENLIGHTEND which can be set but not inherited. When set > it would prevent uid changes from modifying the capabilities > sets. When user space is ready, you can simply #define it to > zero.
Please don't do this. There are 4 bits left, and I need them :-).
Pavel -- I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents me at discuss@linmodems.org
- 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/
| |