From: Chris Wright (chrisw_at_osdl.org)
Date: Wed 12 Nov 2003 - 01:11:07 GMT
* Linas Vepstas (linas_at_linas.org) wrote:
>
> Yeah, well, isn't 'maturity' a synonym for 'almost dead'?
It depends on how you look at it. The fact that it's shipping in
kernels for years (w/out significant changes), and libcap is shipped by
distros help back up the maturity. I think the fact is, it most often
is used as suser() check. So most people don't see the need for better
project pages, docs, howtos, etc. This is open source, so if no one
wants it, it's likely not to get done. The original authors got it
going it seems it didn't get a lot of use, and the project has sort of
hibernated...that's normal ;-)
> I don't buy your answer that "its more or less done" since there are
> obvious gaping holes, and its not done at all:
>
> -- there are no reasonable man pages for getpcaps,
> -- there's also no project web page.
> -- There's no 'howto',
>
> I can gaurentee there there is no (and will be no) widespread adoption
> by users/sysadmins unless there's a HOWTO, no active mailing list, and
> decent man pages.
Agreed. pam_cap.so, for example, could be quite useful...
> > Notably absent are the
> > filesystem capabilities bits, see lkml for the many reasons that this is
> > not popular.
>
> investigating ...
Here's a couple semi-recent threads with Ted (and others) giving some
useful things to take into consideration:
http://marc.theaimsgroup.com/?l=linux-kernel&m=106692811910622&w=2 (Ted's msg)
http://marc.theaimsgroup.com/?t=106673602700004&r=1&w=2 (full thread)
http://marc.theaimsgroup.com/?l=linux-kernel&m=103482590315535&w=2 (Ted's msg)
http://marc.theaimsgroup.com/?t=103478327400010&r=1&w=2 (full thread)
> Well, yes, that was my point. I'm getting the feeling that its implemented
> incorrectly,
First of all, I don't believe SETPCAP is even part of the draft. But
the common capability is used to override a somewhat course grained
privilege. So, lower vs. raise seems to be below the radar of a typical
capability.
> that there should have been a pair of bits: LOWERPCAP and
> RAISEPCAP, instead of SETPCAP. Seems to me that LOWERPCAP, by allowing
> one process to take away the caps of another, is reasonably safe
> and useful. So I was trying ask if you/other gurus see something flawed
> with this line of reasoning.
Even this is a trusted action. A LOWERPCAP privileged process could
quickly disable a process by taking away it's needed, e.g. CAP_NET_BIND,
privilege. Perhaps it's just a DoS, but it's not a no-brainer to give
your proposed priv away. Guess I'd wonder if there's not another way to
achieve this? Also, if you look at the draft, you'll see a SETFCAP (not
raise and lower). For better or worse, I imagine SETPCAP was intended to
be somewhat analogous, and useful since there was not filesytem support.
Sorry, I don't have full history knowledge of the project.
thanks,
-chris
-- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net _______________________________________________ Vserver mailing list Vserver_at_list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver