On Fri, 6 May 2005, Chris Wright wrote: > * Davi Arnaut (davi.arnaut@private) wrote: > > On 5/5/05, Chris Wright <chrisw@private> wrote: > > > Why can't this be done with normal task blobs? The mechanism for > > > populating these could key off of the user struct (IOW, you can share > > > them yourself). This could be more flexible if you don't care to track > > > by uid but by some other grouping. > > > > Yes, but I would have to _duplicate_ the uid system wich essencialy > > does it all. Every hook-hit would implicate a "uid is already in > > our tracking system ?" kind of check. There is no other place for uid > > tracking, the user_struct is already used to track resources (mq_bytes, > > locked_shm, process, et cetera). > > True, I'm just curious, because CKRM, Vserver, PAGG, etc, all want to do > some type of resource tracking, but uid is not the primitive group they > want to track. So, I'm trying to understand usefulness and limitations > of your proposal. I'm having some problems to explain my point due to my poor English skills, but let me try with an example. At an university X there is a big server that is shared by all students, the server is using the classical rlimit approach where a given user Y may only use 200mb of memory. But, if he login multiple times, on each session he will be able to alloc 200mb, somewhat circumventing the limit. Now if a professor is teaching about shared memory and he wants to increase the entire class limit ? This is difficult to implement using the classical pam limits and may be easily circumvented. Through the user (plus some group) hooks I may be able to build a system where an user space daemon may ask to a module: "Hey, how much memory uid 123 is using right now ?" or order: "Hey, limit uid 313 global memory limit to 20mb and to 10 semaphores". With those hooks we can even track and limit per-user actions associating a group of users to students roles, or professor roles. At a bank, sysadmins may want implement modules that tracks specific uids due to suspicious activities without changing their groups or roles. Another interesting audit is to track uids allocations not coming from regular (sshd/getty/..) log-on processes. There are a lot of cases that this kind of tracking would be possible without the user struct hook, but having those hooks in-kernel provides great aid in developing such solutions. > > There are a lot of patches floating around to "fix" this issue. They > > all essentially do the same thing, extending the user struct with a > > bunch of ints. > > There's nothing inherently wrong with adding values to user_struct for > resource tracking. Yes, but they all have to patch the kernel to achieve per-user resource tracking. With the aid of those hooks we could extend the user_struct trough LSM. > > > > For exemple, this patch allows me to implement, with the current set of hooks, > > > > a global per-user task|inode|socket|shm|sem limit and track abuse of those > > > > resources. This is a great feature which can help sysadmins to distribute > > > > resources along a group of users, especially true for servers full of > > > > resource hungry users. > > > > > > Is it simple enough that we can expand existing rlimit infrastructure? > > > > Yes, it very is simple, but rlimit is shell-based limit. Modifying > > that would bring much confusion. But in essence, that's what I'am trying > > to get, a system-wide rlimit (through a uid <-> RBAC role relationship). > > I'm not sure what you mean by a shell-based limit. It's a set of limits > that are managed by the kernel. Just so happens many shells offer a > ulimit built-in to set/getrlimit interface in the kernel. System-wide > is quite doable with rlimits and pam (/etc/security/limits.conf). > Perhaps some code that used these new hooks would help. I'm open to the > idea, but the hooks need something more to justify their use. It's a session-based limit. If you are logged on multiple times, each session will have it's own limit. Supporting global limits on the kernel side is a natural approach. Davi Arnaut > thanks, > -chris >
This archive was generated by hypermail 2.1.3 : Fri May 06 2005 - 20:05:45 PDT