On Fri, 9 Apr 1999, Jonathan Walther wrote:
>
> I think we need to be able to set capabilities on a per user and per
> executable basis. This should not be hard: Simply `and' the capabilities
> masks of the user and the program they're trying to execute. I personally
> favor setting capabilities in the filesystem, but that they only are useful
> on files set executable.
>
> For instance, a user might have the capability set that allows him to access
> graphics memory. But he might not want a particular program that he runs to
> have that same capability.
>
> Jonathan Walther
> Digital Video Broadcasting Systems
> http://216.100.231.12 (requires netscape)
>
>
> On Fri, 9 Apr 1999, Dan Taylor wrote:
>
> > 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/
> >
>
-
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/