lkml.org 
[lkml]   [2000]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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]
\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.041 / U:0.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site