<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jun 24, 2016 at 2:24 PM, Hoyer, Marko (ADITG/SW2) <span dir="ltr"><<a href="mailto:mhoyer@de.adit-jv.com" target="_blank">mhoyer@de.adit-jv.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal">Hi,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">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?</p></div></div></blockquote><div><br></div><div>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().</div><div><br></div><div>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...</div><div><br></div><div>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...</div><div> </div></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Mantas Mikulėnas <<a href="mailto:grawity@gmail.com" target="_blank">grawity@gmail.com</a>></div></div>
</div></div>