lkml.org 
[lkml]   [1999]   [Apr]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Capabilities, this time in elf section
We need to have per-user capabilities, "root" would be the
ability to set these capabilities.

If a program is SUID to a particular user, it _may_ have
any capabilities assigned to that user. By having the capabilities
defined in an ELF header you can run a non-SUID program whose
capabilities do not exceed your own, or a SUID program which
functions fully within its own capability.

The capabilities could _also_ be defined from the filesystem.

But all of the filesystem or executable capability code in the
world means _NOTHING_ if root is the only user with capabilities
beyond what an ordinary user has now, since any executable with
expanded capabilities must then be SUID root.

Of course this also allows for the creation of _less_ priviledged
users that do not have filesystem write permissions or have restricted
execution priviledges.

This is also why we need to leave the SUID bit alone.

John mentioned in the other thread that this data could be stored in
/etc/passwd, there may be better ways to do it but that would work.

Dan Taylor
On Fri, 9 Apr 1999, Ingo Molnar wrote:

>
> On Fri, 9 Apr 1999, Ernest JW ter Kuile wrote:
>
> > > being able to set the setuid root bit is [should be?] a capability itself,
> > > root does not ...
> >
> > no it isn't !
> >
> > that bit isn't a setuid *root* bit at all if the owner of the file isn't
> > root.
> > anybody should still be able to set that bit if he want. the capability
> > you mean is the chown/grp capability.
>
> yes, this is what i ment by:
>
> > > This breaks symmetry a little bit but i dont think it's a problem.)
>
> > *don't* change the meaning of the setuid bit please.
>
> i dont think this is a problem. In the future setuid root will no more
> have it's old meaning. So i can see no problem with changing _some_ of the
> semantics. At some point there will be no extra rights attached to uid 0.
>
> > you can however remove root if there is somwhere a database of personal
> > capabilities per user (ala passwd, shadow, etc...), then by setting
> > setuid to
> > any user, a binary could get a subset (or all) of *that* users
> > capabilities and no more.
>
> i never said that setuid _nonroot_ should change. We obviously need it for
> things like mail delivery, it's a feature. What i proposed was to handle
> setuid root (and only setuid root) slightly differently. [since setuid
> root is exactly the thing we want to redesign/replace by capabilities] Do
> you see my point?
>
> -- mingo
>
>
> -
> 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/
>


-
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:51    [W:3.528 / U:0.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site