Elias Pipping <[EMAIL PROTECTED]> wrote:

> On Sat, Jan 26, 2008 at 08:58:34AM +0100, Jim Meyering wrote:
>>
>> Please do this as root:
>>
>>   cd coreutils-6.10/src
>>   ./id -a
>>   ./rm -rf f g
>>   echo a > f
>>   ./chown +0:+0 f
>>   ls -ld . f
>>   ./cp f g
>>   ls -l g
>>
>> and look at the output.
>> The final ls should show g with group "root".
>
> For some reason it doesn't.
>
>   # cd coreutils-6.10/src
>   # ./id -a
>   uid=0(root) gid=0(wheel) groups=0(wheel),1(daemon),8(procview),
>       2(kmem),29(certusers),3(sys),9(procmod),4(tty),
>       102(com.apple.sharepoint.group.2),5(operator),80(admin),20(staff),
>       101(com.apple.sharepoint.group.1)
>   # ./rm -rf f g
>   # echo a > f
>   # ./chown +0:+0 f
>   # ls -ld . f
>   drwxr-xr-x  3 pipping  staff  11186 Jan 26 12:29 .
>   -rw-r--r--  1 root     wheel      2 Jan 26 12:29 f
>   # ./cp f g
>   # ls -l g
>   -rw-r--r--  1 root  staff  2 Jan 26 12:29 g

That suggests that the bogus group is set by cp's open call.  I suspect
some sort of ACL mechanism that specifies "staff" as the default group --
or maybe some rule says "inherit group from parent directory".

Do you see the same behavior if you run those commands in /tmp?
(in place of "./", you'll need "/abs/path-to/coreutils-6.10/src/")


_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Reply via email to