Re: [systemd-devel] x bits set on /run/systemd/private, any particular reason?
Hi, Thx for the answer. >> Either way, +x has no meaning on sockets (only +w matters). I guess this was the fact I was actually interested in. Best regards Marko Hoyer Software Group II (ADITG/SW2) Tel. +49 5121 49 6948 From: Mantas Mikulėnas [mailto:graw...@gmail.com] Sent: Freitag, 24. Juni 2016 18:31 To: Hoyer, Marko (ADITG/SW2) Cc: systemd Mailing List Subject: Re: [systemd-devel] x bits set on /run/systemd/private, any particular reason? On Fri, Jun 24, 2016 at 2:24 PM, Hoyer, Marko (ADITG/SW2) mailto:mho...@de.adit-jv.com>> wrote: Hi, I’m not an expert on Linux access right management but I’m wondering why systemd’s private socket (/run/systemd/private) has the x bits set. Did it happen accidently? Immediately after bind(), the socket will have all permissions that weren't masked out by the current umask – there doesn't seem to be an equivalent to the mode parameter of open(). The default umask for init is 0; it seems that while systemd does set a more restrictive umask when necessary, it doesn't bother doing so when setting up the private socket, so it ends up having 0777 permissions by default... Either way, +x has no meaning on sockets (only +w matters). Checking `find /run -type s -ls`, it seems services aren't very consistent whether to keep or remove it for their own sockets... -- Mantas Mikulėnas mailto:graw...@gmail.com>> ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] x bits set on /run/systemd/private, any particular reason?
On Fri, 24.06.16 11:24, Hoyer, Marko (ADITG/SW2) (mho...@de.adit-jv.com) wrote: > Hi, > > I'm not an expert on Linux access right management but I'm wondering > why systemd's private socket (/run/systemd/private) has the x bits > set. Did it happen accidently? We don't do that explicitly. That's simply what the kernel does if you invoke bind(). Compare: $ socat UNIX-LISTEN:/tmp/fff - ^Z [1]+ Stopped socat UNIX-LISTEN:/tmp/fff - $ stat /tmp/fff File: '/tmp/fff' Size: 0 Blocks: 0 IO Block: 4096 socket Device: 2bh/43d Inode: 3604282 Links: 1 Access: (0775/srwxrwxr-x) Uid: ( 1000/ lennart) Gid: ( 1000/ lennart) Context: unconfined_u:object_r:user_tmp_t:s0 Access: 2016-06-24 20:28:56.692037876 +0200 Modify: 2016-06-24 20:28:56.692037876 +0200 Change: 2016-06-24 20:28:56.692037876 +0200 Birth: - $ fg socat UNIX-LISTEN:/tmp/fff - ^C And this doesn't matter much as the x bit has no real effect on AF_UNIX sockets. (much like i has no effect on fifos or symlinks). Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] x bits set on /run/systemd/private, any particular reason?
On Fri, Jun 24, 2016 at 2:24 PM, Hoyer, Marko (ADITG/SW2) < mho...@de.adit-jv.com> wrote: > Hi, > > > > I’m not an expert on Linux access right management but I’m wondering why > systemd’s private socket (/run/systemd/private) has the x bits set. Did it > happen accidently? > Immediately after bind(), the socket will have all permissions that weren't masked out by the current umask – there doesn't seem to be an equivalent to the mode parameter of open(). The default umask for init is 0; it seems that while systemd does set a more restrictive umask when necessary, it doesn't bother doing so when setting up the private socket, so it ends up having 0777 permissions by default... Either way, +x has no meaning on sockets (only +w matters). Checking `find /run -type s -ls`, it seems services aren't very consistent whether to keep or remove it for their own sockets... -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel