[lkml]   [2000]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Capabilities
Khimenko Victor <> wrote:
>[snip snip]
> (for example now apache start with UID=0 so it has all capabilities and
> then with change of UID it'll drop all capabilities; in trusted system even
> with change of UID capabilities will retain: UID==0 is not special in "trusted
> Linux"). So system-wide option looks unavoidable :-((

Just because I'm a frick'n idiot, why can't we bind capability
mask to UID/GIDs? That would solve a lot of the administration and
``what happens if we mount a FAT filesystem?'' issues, IMHO.

* UID/GID capability masks (/etc/capabilites?) would be loaded
by /sbin/init. A user with the capability (CAP_SETUCAP?)
could modify current mapping via /proc/sys/????/capabilty.
* The capabilities are only acquired on SUID or login. Ie
r-xr-xr-x man man /usr/bin/man - No capabilties
r-sr-xr-x net bin /usr/bin/ping - Capabilties of the ``net'' user
r-xr-sr-x bin audio /usr/bin/play - Capabilties of the ``audio'' group

* Programs can _drop_ capabilties. If kernel support for capabities
is diabled, or their UID/GID is not in the mapping table, the
capability system call is a no-op.

* Allows for distributions that can turn on or off capability
support easily. With no need to rewrite existing daemons/applications.

* No need to change any filesystems. This technique would work
even on old Minix filesystems.

* Easy administration - just do the same ``look for files that
are SUID and owned by this UID'' that we already do.

So what do ya'll think?

Jason McMullan, Senior Linux Consultant, Linuxcare, Inc.
412.422.8077 tel, 415.701.0792 fax,
Linuxcare. Support for the revolution.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:56    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean