Re: [systemd-devel] x bits set on /run/systemd/private, any particular reason?

[Hoyer, Marko (ADITG/SW2)]

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) 
<mho...@de.adit-jv.com<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 <graw...@gmail.com<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?

[Lennart Poettering]

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?

[Mantas Mikulėnas]

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

[systemd-devel] x bits set on /run/systemd/private, any particular reason?

[Hoyer, Marko (ADITG/SW2)]

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?

Can someone explain?

Best regards

Marko Hoyer
Advanced Driver Information Technology GmbH
Software Group II (ADITG/SW2)
Robert-Bosch-Str. 200
31139 Hildesheim
Germany
Tel. +49 5121 49 6948
Fax +49 5121 49 6999
mho...@de.adit-jv.com
ADIT is a joint venture company of Robert Bosch GmbH/Robert Bosch Car 
Multimedia GmbH and DENSO Corporation
Sitz: Hildesheim, Registergericht: Amtsgericht Hildesheim HRB 3438
Geschäftsführung: Wilhelm Grabow, Ken Yaguchi
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel