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 

On Fri, Jun 24, 2016 at 2:24 PM, Hoyer, Marko (ADITG/SW2) 
<mho...@de.adit-jv.com<mailto:mho...@de.adit-jv.com>> wrote:

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 <graw...@gmail.com<mailto:graw...@gmail.com>>
systemd-devel mailing list

Reply via email to