* 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. > 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. > > > 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. thanks, -chris
This archive was generated by hypermail 2.1.3 : Fri May 06 2005 - 01:00:21 PDT