Messages in this thread | | | Date | Wed, 2 Feb 2000 14:58:05 +0100 | From | Marek Habersack <> | Subject | Re: RFC: capability to limit/allow access to various system info |
| |
* Sean Hunter said: > On Wed, Feb 02, 2000 at 01:23:41PM +0100, Marek Habersack wrote: > > safe when allowed to do too much... For now I have just written a daemon > > process that runs chrooted as root and the CGI script connects to it > > (running as specific user), passess its credentials and if they match a > > compile-time defaults, the quota information is returned and shown to the > > user. Well... it works, but is far from elegant and much more complicated > > than it would be if I had the capabilities we're discussing now. > > My apologies for my previous post. I missed this bit. I don't think > that the simplicity gained by removing the daemon would justify adding > additional kernel caps. It's just an example. Using a general CAP_SYS_INFO capability you could build safe resource monitoring daemons running as otherwise non-privileged users. Also, in the time of web-based access portals to the user's account you could provide them with any kind of information about their accounts without the need of executing any code privileged to anything more than just reading some information from the kernel. Right now reading many bits of information requires UID0 access which is _NOT_ necessary when you only want to retrieve information. I was just thinking about another example - say you've got a server when many users log-in and stay logged in for quite a while or leave processes in the background. Now, you want to enforce some restrictions on the number of logins, number of tasks left after logging out, you also want to gather per-user resource usage data (for example for statistical purposes). Of course, there are daemons out there that both monitor and enforce these limits but they all have to run as UID 0. Now, if we had, for example, CAP_SYS_INFO in addition to other, already existing, capabilities that allow manipulating several system parameters, we could run our hypothetical daeon with the CAP_SYS_INFO and CAP_WRITE_ACCESS_TO_SOMETHING | CAP_KILL_USER_PROCESS (just two invented names :)) raised initially on the startup then dropped by the process leaving just CAP_SYS_INFO up, so that it can monitor the parameters we're interested in and raise the other, more powerful, capabilities when need arises to kill some processes or do stuff like that.
marek [unhandled content-type:application/pgp-signature] | |