lkml.org 
[lkml]   [1999]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.056 / U:0.432 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site