On Mon, Aug 30, 2021 at 10:57:59PM +0200, Rainer Dorsch wrote: > Hmm...your example works for me as well > > rd@h370:~/tmp.nobackup$ sudo touch /tmp/123; sudo chgrp video /tmp/123; sudo > chmod 664 /tmp/123 > [sudo] Passwort für rd: > rd@h370:~/tmp.nobackup$ ls -l /tmp/123 > -rw-rw-r-- 1 root video 0 30. Aug 22:52 /tmp/123 > rd@h370:~/tmp.nobackup$ id > uid=2809(rd) gid=2809(rd) Gruppen=2809(rd),4(adm),20(dialout),21(fax), > 24(cdrom),25(floppy),27(sudo),30(dip),44(video),46(plugdev),100(users), > 114(lpadmin),118(scanner),126(docker),127(vboxusers),130(i2psvc), > 131(wireshark),141(libvirt),1000(sispmctl) > rd@h370:~/tmp.nobackup$ echo stuff >> /tmp/123 > rd@h370:~/tmp.nobackup$ > > As soon as I do a chown to a non-root user on /tmp/123 it does not work for > me > anymore. > > Is root somehow treated differently as other users?
unicorn:~$ ls -l /tmp/123 -rw-rw-r-- 1 daemon video 0 Aug 30 17:00 /tmp/123 unicorn:~$ echo stuff >> /tmp/123 bash: /tmp/123: Permission denied That is interesting! unicorn:~$ strace bash -c 'echo stuff >> /tmp/123' [...] openat(AT_FDCWD, "/tmp/123", O_WRONLY|O_CREAT|O_APPEND, 0666) = -1 EACCES (Permission denied) As far as I can see, this is a kernel bug. Unless I'm overlooking something...? For fun, I also tried it with the primary group: unicorn:~$ id uid=1000(greg) gid=1000(greg) groups=1000(greg),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),108(netdev) unicorn:~$ sudo chgrp 1000 /tmp/123 unicorn:~$ echo stuff >> /tmp/123 bash: /tmp/123: Permission denied unicorn:~$ ls -l /tmp/123 -rw-rw-r-- 1 daemon greg 0 Aug 30 17:00 /tmp/123 So it's not just the secondary group that's causing it.
