Wow. So apparently things are even more broken than I though. Let's play, "What group am I in?" root_at_group-testing:/usr/home/rstone # cd /tmp root_at_group-testing:/tmp # pw groupadd testing root_at_group-testing:/tmp # mkdir testdir root_at_group-testing:/tmp # chown root:testing testdir/ root_at_group-testing:/tmp # chmod g+rwx testdir/ root_at_group-testing:/tmp # pw usermod root_at_group-testing:/tmp # pw groupmod testing -m rstone root_at_group-testing:/tmp # id rstone uid=1001(rstone) gid=1001(rstone) groups=1001(rstone),0(wheel),1002(testing) root_at_group-testing:/tmp # exit $ id uid=1001(rstone) gid=1001 groups=1001,0 $ id rstone uid=1001(rstone) gid=1001 groups=1001 $ touch /tmp/testdir/testfile touch: /tmp/testdir/testfile: Permission denied $ ls -ld /tmp/testdir/ drwxrwxr-x 2 root 1002 512 Nov 17 11:07 /tmp/testdir/ My original complaint that /etc/group gets permissions of 0600 is a result of a bug in libutil, which bapt_at_ ported pw to use in r242349. The new group manipulation API using mktemp to create a temporary file, writes the new group database to the temp file and then renames the temp file to /etc/group. The problem here is that mktemp creates a file with a mode of 600, and libutil never chmods it. That should be pretty trivial to fix. I have no idea what's happening in my example above, though. Baptiste, I have to ask: how much testing did r242349 receive before it was committed?Received on Sat Nov 17 2012 - 15:20:22 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:32 UTC