I'm scrutinizing the capabilities to find out how consistently they are
implemented. Are capabilities supposed to be 'consistent' -- other than
root initially gets all caps and normal users get zero?
If they aren't consistent, are they bugs that need to be fixed?
For example, in the "access" system call I see:
/* access() needs to use the real uid/gid, not the effective uid/gid.
* We do this by temporarily clearing all FS-related capabilities and
* switching the fsuid/fsgid around to the real ones.
*/
asmlinkage long sys_access(const char * filename, int mode)
{...
/* Clear the capabilities if we switch to a non-root user */
if (current->uid)
cap_clear(current->cap_effective);
else
current->cap_effective = current->cap_permitted;
---------
This would seem to be incorrect behavior for a privileged-based capability system. In such one would not simply check
for 'uid==0' and take some action. Any given user, say user 'backup', may
be allowed a specific capability. It's conceivable that root could have
an empty capability set, but certain users may have 'some' capabilities.
So I'm slight confused as to the intent of capabilities and/or where
'we' desire to go. I'd like to see a 'least-privilege' model, whereas I
think the above code is improperly(?) using capabilities as a bounding set on
'root'.
For CAP_CHOWN, the model is 'least-privilege' -- i.e. CAP_CHOWN could
be possessed by a non-root UID and/or it could be turned off for root.
BTW -- _POSIX_ACL, referenced in capabitilies.h, appears nowhere in
the kernel. Should it be removed or noted as something for 'future'
implementation?
???
-linda
-- Linda A Walsh | Trust Technology, Core Linux, SGI law@sgi.com | Voice: (650) 933-5338- 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/
This archive was generated by hypermail 2b29 : Tue May 23 2000 - 21:00:24 EST