Messages in this thread | | | Subject | Re: Capabilities | Date | Tue, 29 Feb 2000 09:53:25 -0300 | From | Horst von Brand <> |
| |
Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil> said:
[...]
> I think the "forced" capabilities permit totally unprivileged users to > accomplish something that does require privilege - such as changing a > password. It doesn't grant the ability to change just any password; only > the password of the user using the passwd utility, even then the user > must provide the old password. Changing any password requires additional > capabilities/role definition (such as security administrator - there may > be several capabilities used to define the role of security admin).
Please don't. That way you end up with thousands of capabilities, and the whole mess becomes unmanageable. The way this should work, IMHO, is like passwd(1) does today: It has the capability of changing any password, but the _program_ restricts this to the individual user's password after extra authentification. Sure, it is more orthogonal to use just one mechanism to handle all security, but pragmatically it is probably better to design a mix. The total complexity (kernel + userland) should be roughly the same both ways (if there isn't an advantage due to better access to the filesystem for userland), so that doesn't count as an argument.
-- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
- 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/
| |