groups

[tmetro-blu-5a1Jt6qxUNc at public.gmane.org (Tom Metro)]

Bill Bogstad wrote:
> Laura Conrad wrote:
>> You can tell this system antedates X windows, can't you?
> 
> It antedates virtual terminals and even the idea of having more then
> one group for a process.
> 
> The newgrp command remains, but is almost useless. ... As you point
> out, in the new modern X windows world; we have whole clouds of
> processes running around. Although they may share
> parent/child/sibling relationships the kernel treats their privileges
> as independent from each other.
> ...
> One could write a setuid root program to start a new program with a
> new set of groups based on the /etc/groups file, but I don't think
> there is anyway to retroactively change the groups on a set of
> already started programs.

Conceptually addgroup(8) could iterate through /proc looking for 
processes owned by the relevant UID and update the cached group 
membership for each. Of course some kernel tweaks would be needed.

Makes one wonder why something like this hasn't already been 
implemented. The reason might be that more powerful and flexible access 
control mechanisms, such as ACLs, have supplanted groups, and don't 
suffer from the same caching effects.

I haven't played around with ACLs on Linux, but they might be a better 
way of addressing the original problem. See 'man acl'.

  -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/