In fact, group ownership of newly created files doesn't seem to work
at all. I can't believe it's taken me 5 years to notice this one...
Changing a shell's group does not seem to affect the ownership of new
files created once the group has been changed:
13:57:11 tjrc_at_pcs3g:/tmp$ id
uid=10787(tjrc) gid=10(staff) groups=0(system),706(ssg),558(intweb),
555(w3adm),102(informatics)
13:57:16 tjrc_at_pcs3g:/tmp$ ls -l foo
ls: foo not found
13:57:37 tjrc_at_pcs3g:/tmp$ newgrp ssg
13:57:43 tjrc_at_pcs3g:~$ cd /tmp
13:57:45 tjrc_at_pcs3g:/tmp$ id
uid=10787(tjrc) gid=706(ssg) groups=0(system),706(ssg),558(intweb),555
(w3adm),102(informatics)
So the gid has changed correctly, but
13:57:51 tjrc_at_pcs3g:/tmp$ /bin/touch foo
13:57:58 tjrc_at_pcs3g:/tmp$ ls -l foo
-rw-r--r-- 1 tjrc system 0 Jan 15 13:57 foo
13:58:00 tjrc_at_pcs3g:/tmp$
Not only has it not created the file with the group ownership that's
my primary group, or the group to which I have changed, but it seems
to have chosen the first group of which I am a member (0).
Now, only the system group is actually in the /etc/group file, the
others are all NIS groups.
I thought it might be the case that newgrp(1) only works with groups
which are present in the /etc/group file, so I edited the group file
to make a local copy of the ssg group, and the issue persists.
I'm aware of the historical bug that affected people with groups
split over multiple lines in /etc/group, but that isn't the case here.
But then I went back ignoring newgrp at all, just checked what
ownership my files are being created with, and lo, it's "system" not
my primary group of "staff". What?!
Does anyone know what's going on? Is this some strange configuration
option of AdvFS that we've got wrong? It seems likely it's actually
at the filesystem level, since the problem also affects Linux NFS
clients, iff the file server is running Tru64.
Can anyone help me out here?
Tim
Received on Mon Jan 15 2007 - 14:10:06 NZDT