lkml.org 
[lkml]   [2000]   [Feb]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Capabilities
Date
From
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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.048 / U:1.852 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site