> > 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/