lkml.org 
[lkml]   [1998]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: suser() -> capable() for linux/*
Date
From

Looking at the capabilities patches, I can't help wondering if they are
granular enough.

For example, I want certain users to be able to manipulate my second network
card, but not the main one. I certainly don't want them to have all the
privileges that CAP_NET_ADMIN gives.

CAP_SYS_ADMIN is even worse - I'll want my own user to be able to set up the
frame buffer address on the TV card, but that's all.

I'd also like a CAP_NETWORK, to control _any_ network access, ideally with the
possibility of allowing traffic only on certain devices, although that's not
quite feasible ATM. With the SO_BINDTODEVICE code in place, I suppose one
could enforce "only loopback", though.

Perhaps such granularity could be achieved by adding an opaque field to the
cap_t, which could be to further qualify the capability, for example in the
case of CAP_SYS_ADMIN it could contain a dev_t & mask to specify the device(s)
to which access is permitted.


---- ---- ----
David Woodhouse, Robinson College, CB3 9AN, England. (+44) 0976 658355
Dave@imladris.demon.co.uk http://www.imladris.demon.co.uk
finger pgp@dwmw2.robinson.cam.ac.uk for PGP key.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

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