Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #239471 > unrolled thread

Permission Questions

Back to article view | Back to linux.debian.user

Contents

  Permission Questions Rainer Dorsch <ml@bokomoko.de> - 2021-08-30 21:50 +0200
    Re: Permission Questions Greg Wooledge <greg@wooledge.org> - 2021-08-30 22:00 +0200
      Re: Permission Questions Rainer Dorsch <ml@bokomoko.de> - 2021-08-30 23:00 +0200
        Re: Permission Questions Greg Wooledge <greg@wooledge.org> - 2021-08-30 23:10 +0200
          Re: Permission Questions Andy Smith <andy@strugglers.net> - 2021-08-30 23:30 +0200
            Re: Permission Questions Greg Wooledge <greg@wooledge.org> - 2021-08-31 00:10 +0200
              Re: Permission Questions Rainer Dorsch <ml@bokomoko.de> - 2021-08-31 11:00 +0200
    Re: Permission Questions IL Ka <kazakevichilya@gmail.com> - 2021-08-30 22:00 +0200

#239471 — Permission Questions

Hi,

I am looking for advice how to implement best this kind of usecase:

User rd creates a file on /tmp:

rd@h370:~/tmp.nobackup$ touch /tmp/123
rd@h370:~/tmp.nobackup$ chgrp users /tmp/123
rd@h370:~/tmp.nobackup$ chmod g+w /tmp/123
rd@h370:~/tmp.nobackup$ ls -l /tmp/123
-rw-rw-r-- 1 rd users 0 30. Aug 20:42 /tmp/123
rd@h370:~/tmp.nobackup$ 

User ka overwrites it with the content of another file (atomically):

ka@h370:~$ echo test > 123
ka@h370:~$ mv 123 /tmp/123
mv: cannot move '123' to '/tmp/123': Operation not permitted
ka@h370:~$ id
uid=1401(ka) gid=1401(ka) groups=1401(ka),20(dialout),21(fax),24(cdrom),
30(dip),44(video),46(plugdev),100(users),1000(sispmctl)
ka@h370:~$ 

Although ka has write permissions as group member, this does not work.

Maybe moving removes a node in /tmp, so I am trying to append to the file as a 
test:

rd@h370:~/tmp.nobackup$ touch /tmp/123 
rd@h370:~/tmp.nobackup$ chgrp users /tmp/123 
rd@h370:~/tmp.nobackup$ chmod g+w /tmp/123 
rd@h370:~/tmp.nobackup$ ls -l /tmp/123 
-rw-rw-r-- 1 rd users 0 30. Aug 20:35 /tmp/123 
rd@h370:~/tmp.nobackup$ 

ka@h370:~$ id 
uid=1401(ka) gid=1401(ka) Gruppen=1401(ka),20(dialout),21(fax),24(cdrom),
30(dip),44(video),46(plugdev),100(users),1000(sispmctl) 
ka@h370:~$ ls -l /tmp/123 
-rw-rw-r-- 1 rd users 0 30. Aug 20:35 /tmp/123 
ka@h370:~$ echo test >> /tmp/123 
-bash: /tmp/123: Permission denied 
ka@h370:~$ 

Even that does not work. Why not?

Is there something special with /tmp?

kan@h370:~$ ls -ld /tmp
drwxrwxrwt 26 root root 32768 Aug 30 20:51 /tmp
ka@h370:~$ 


Now attempting to do the same in a regular home directory:

rd@h370:~/tmp.nobackup$ touch 123
rd@h370:~/tmp.nobackup$ chgrp users 123
rd@h370:~/tmp.nobackup$ chmod g+w 123
rd@h370:~/tmp.nobackup$ 

ka@h370:~$ echo test >> /home/rd/tmp.nobackup/123
ka@h370:~$

Appending works!

But replacing the file with a mv command does not work in the /home directory:

rd@h370:~/tmp.nobackup$ touch 123       
rd@h370:~/tmp.nobackup$ ls -l 123 
-rw-rw-r-- 1 rd users 5 30. Aug 20:39 123 
rd@h370:~/tmp.nobackup$ 

ka@h370:~$ mv 123 /home/rd/tmp.nobackup/123 
mv: cannot move '123' to '/home/rd/tmp.nobackup/123': Permission denied 
ka@h370:~$ 

If I redirect the output and overwrite the file instead of using mv,  the 
system allows me to do that:

rd@h370:~/tmp.nobackup$ touch 123
rd@h370:~/tmp.nobackup$ chgrp users 123
rd@h370:~/tmp.nobackup$ chmod g+w 123
rd@h370:~/tmp.nobackup$ ls -l 123
-rw-rw-r-- 1 rd users 0 30. Aug 20:51 123
rd@h370:~/tmp.nobackup$ 

ka@h370:~$ echo test > 123
ka@h370:~$ cat 123 > /home/rd/tmp.nobackup/123 
ka@h370:~$ cat /home/rd/tmp.nobackup/123
test
ka@h370:~$ 

It is weird that mv is forbidden, but redirecting the output is allowed. The 
end result on the file system would be the same!

Downside of redirecting is that /home/rd/tmp.nobackup/123 is not updated 
atomically (assuming another process is reading it asynchronically).

So essentially what I want to achieve:
- Updating a file atomically
- Preferably in /tmp

Any advice or hint is welcome.

Thanks
Rainer

-- 
Rainer Dorsch
http://bokomoko.de/

[toc] | [next] | [standalone]

#239474

On Mon, Aug 30, 2021 at 09:01:33PM +0200, Rainer Dorsch wrote:
> rd@h370:~/tmp.nobackup$ ls -l /tmp/123
> -rw-rw-r-- 1 rd users 0 30. Aug 20:42 /tmp/123

> User ka overwrites it with the content of another file (atomically):
> 
> ka@h370:~$ echo test > 123
> ka@h370:~$ mv 123 /tmp/123
> mv: cannot move '123' to '/tmp/123': Operation not permitted

In order to perform this move, ka would first need to unlink the
existing /tmp/123 file.  ka cannot do that, because the /tmp directory
is "sticky".  Only "rd" (or root) can do it.

> Maybe moving removes a node in /tmp,

Yes.  You can verify with strace if you're curious enough.

> so I am trying to append to the file as a 
> test:
> 
> -rw-rw-r-- 1 rd users 0 30. Aug 20:35 /tmp/123 

> ka@h370:~$ id 
> uid=1401(ka) gid=1401(ka) Gruppen=1401(ka),20(dialout),21(fax),24(cdrom),
> 30(dip),44(video),46(plugdev),100(users),1000(sispmctl) 
> ka@h370:~$ ls -l /tmp/123 
> -rw-rw-r-- 1 rd users 0 30. Aug 20:35 /tmp/123 
> ka@h370:~$ echo test >> /tmp/123 
> -bash: /tmp/123: Permission denied 

That one should have worked, due to the secondary group membership.

unicorn:~$ sudo touch /tmp/123; sudo chgrp video /tmp/123; sudo chmod 664 /tmp/123
[sudo] password for greg: 
unicorn:~$ ls -l /tmp/123
-rw-rw-r-- 1 root video 0 Aug 30 15:56 /tmp/123
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:~$ echo stuff >> /tmp/123
unicorn:~$ 

It works for me.  Is your /tmp a non-Unix file system, or is it mounted
with any unusual options?

[toc] | [prev] | [next] | [standalone]

#239479

Am Montag, 30. August 2021, 21:58:47 CEST schrieb Greg Wooledge:
> On Mon, Aug 30, 2021 at 09:01:33PM +0200, Rainer Dorsch wrote:
> > rd@h370:~/tmp.nobackup$ ls -l /tmp/123
> > -rw-rw-r-- 1 rd users 0 30. Aug 20:42 /tmp/123
> > 
> > User ka overwrites it with the content of another file (atomically):
> > 
> > ka@h370:~$ echo test > 123
> > ka@h370:~$ mv 123 /tmp/123
> > mv: cannot move '123' to '/tmp/123': Operation not permitted
> 
> In order to perform this move, ka would first need to unlink the
> existing /tmp/123 file.  ka cannot do that, because the /tmp directory
> is "sticky".  Only "rd" (or root) can do it.
> 
> > Maybe moving removes a node in /tmp,
> 
> Yes.  You can verify with strace if you're curious enough.
> 
> > so I am trying to append to the file as a
> > test:
> > 
> > -rw-rw-r-- 1 rd users 0 30. Aug 20:35 /tmp/123
> > 
> > ka@h370:~$ id
> > uid=1401(ka) gid=1401(ka) Gruppen=1401(ka),20(dialout),21(fax),24(cdrom),
> > 30(dip),44(video),46(plugdev),100(users),1000(sispmctl)
> > ka@h370:~$ ls -l /tmp/123
> > -rw-rw-r-- 1 rd users 0 30. Aug 20:35 /tmp/123
> > ka@h370:~$ echo test >> /tmp/123
> > -bash: /tmp/123: Permission denied
> 
> That one should have worked, due to the secondary group membership.
> 
> unicorn:~$ sudo touch /tmp/123; sudo chgrp video /tmp/123; sudo chmod 664
> /tmp/123 [sudo] password for greg:
> unicorn:~$ ls -l /tmp/123
> -rw-rw-r-- 1 root video 0 Aug 30 15:56 /tmp/123
> 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:~$ echo stuff >> /tmp/123
> unicorn:~$
> 
> It works for me.  Is your /tmp a non-Unix file system, or is it mounted
> with any unusual options?

Thanks for testing and your quick response.

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?

I am not aware of special mount options for /tmp, it should be a standard 
installation:

rd@h370:~/tmp.nobackup$ mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs 
(rw,nosuid,relatime,size=16342996k,nr_inodes=4085749,mode=755)
devpts on /dev/pts type devpts 
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs 
(rw,nosuid,nodev,noexec,relatime,size=3273064k,mode=755)
/dev/mapper/b370--vg-root on / type ext4 (rw,relatime,errors=remount-ro)
securityfs on /sys/kernel/security type securityfs 
(rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
cgroup2 on /sys/fs/cgroup type cgroup2 
(rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
efivarfs on /sys/firmware/efi/efivars type efivarfs 
(rw,nosuid,nodev,noexec,relatime)
none on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs 
(rw,relatime,fd=30,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=13462)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
fusectl on /sys/fs/fuse/connections type fusectl 
(rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
sunrpc on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
/dev/sda2 on /boot type ext2 (rw,relatime)
/dev/sda1 on /boot/efi type vfat 
(rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-
ro)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc 
(rw,nosuid,nodev,noexec,relatime)
-hosts on /mnt/net type autofs 
(rw,relatime,fd=6,pgrp=1674,timeout=60,minproto=5,maxproto=5,indirect,pipe_ino=19859)
tmpfs on /run/user/113 type tmpfs 
(rw,nosuid,nodev,relatime,size=3273064k,nr_inodes=818266,mode=700,uid=113,gid=117)
tmpfs on /run/user/2809 type tmpfs 
(rw,nosuid,nodev,relatime,size=3273064k,nr_inodes=818266,mode=700,uid=2809,gid=2809)
-hosts on /mnt/net/fs/mnt/disk/data type autofs 
(rw,relatime,fd=6,pgrp=1674,timeout=60,minproto=5,maxproto=5,offset,pipe_ino=19859)
-hosts on /mnt/net/fs/mnt/disk/scratch type autofs 
(rw,relatime,fd=6,pgrp=1674,timeout=60,minproto=5,maxproto=5,offset,pipe_ino=19859)
-hosts on /mnt/net/fs/mnt/disk/scratch2 type autofs 
(rw,relatime,fd=6,pgrp=1674,timeout=60,minproto=5,maxproto=5,offset,pipe_ino=19859)
-hosts on /mnt/net/fs/mnt/disk/smarthome type autofs 
(rw,relatime,fd=6,pgrp=1674,timeout=60,minproto=5,maxproto=5,offset,pipe_ino=19859)
fs:/mnt/disk/data on /mnt/net/fs/mnt/disk/data type nfs4 
(rw,nosuid,nodev,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.7.203,local_lock=none,addr=192.168.7.2)
portal on /run/user/2809/doc type fuse.portal 
(rw,nosuid,nodev,relatime,user_id=2809,group_id=2809)
fs:/mnt/disk/scratch on /mnt/net/fs/mnt/disk/scratch type nfs4 
(rw,nosuid,nodev,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.7.203,local_lock=none,addr=192.168.7.2)
rd@h370:~/tmp.nobackup$

Thanks
Rainer

-- 
Rainer Dorsch
http://bokomoko.de/

[toc] | [prev] | [next] | [standalone]

#239481

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.

[toc] | [prev] | [next] | [standalone]

#239484

Hello,

On Mon, Aug 30, 2021 at 05:07:16PM -0400, Greg Wooledge wrote:
> 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...?

I think it's the sysctl fs.protected_regular:

    https://unix.stackexchange.com/a/503169

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#239487

On Mon, Aug 30, 2021 at 09:29:14PM +0000, Andy Smith wrote:
> Hello,
> 
> On Mon, Aug 30, 2021 at 05:07:16PM -0400, Greg Wooledge wrote:
> > 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...?
> 
> I think it's the sysctl fs.protected_regular:
> 
>     https://unix.stackexchange.com/a/503169

I think you're right.  The changed behavior doesn't happen in /srv (only
in /tmp), nor does it happen on a buster system.

According to <https://www.spinics.net/lists/fedora-devel/msg252453.html>
and <https://github.com/systemd/systemd/blob/main/NEWS>, the change
actually happened in... wait for it... systemd.

*sigh*

[toc] | [prev] | [next] | [standalone]

#239506

Am Dienstag, 31. August 2021, 00:00:02 CEST schrieb Greg Wooledge:
> On Mon, Aug 30, 2021 at 09:29:14PM +0000, Andy Smith wrote:
> > Hello,
> > 
> > On Mon, Aug 30, 2021 at 05:07:16PM -0400, Greg Wooledge wrote:
> > > 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...?
> > 
> > I think it's the sysctl fs.protected_regular:
> >     https://unix.stackexchange.com/a/503169
> 
> I think you're right.  The changed behavior doesn't happen in /srv (only
> in /tmp), nor does it happen on a buster system.
> 
> According to <https://www.spinics.net/lists/fedora-devel/msg252453.html>
> and <https://github.com/systemd/systemd/blob/main/NEWS>, the change
> actually happened in... wait for it... systemd.
> 
> *sigh*

Hi Andy and Greg,

many thanks for you very helpful replies, that explains the behavior fully.

Rainer

-- 
Rainer Dorsch
http://bokomoko.de/

[toc] | [prev] | [next] | [standalone]

#239475

[Multipart message — attachments visible in raw view] — view raw

>
>
> Is there something special with /tmp?
>

Do you have sticky bit on `/tmp`?

> For directories, when a directory's sticky bit is set, the filesystem
treats the files in such directories in a special way so only the file's
owner, the directory's owner, or root user can rename or delete the file.

https://en.wikipedia.org/wiki/Sticky_bit


>
> kan@h370:~$ ls -ld /tmp
> drwxrwxrwt 26 root root 32768 Aug 30 20:51 /tmp
> ka@h370:~$
>
>
AFAIK 't' means yes, you have it.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web