[systemd-devel] [PATCH] tmpfiles: only change device permissions if mknod succeeded

Jan Synacek jsynacek at redhat.com
Wed Oct 29 02:37:38 PDT 2014


Tom Gundersen <teg at jklm.no> writes:

> On Mon, Oct 27, 2014 at 4:53 PM, Tom Gundersen <teg at jklm.no> wrote:
>> On Mon, Oct 27, 2014 at 4:48 PM, Lennart Poettering
>> <mzerqung at 0pointer.de> wrote:
>>> On Sat, 25.10.14 01:36, Tom Gundersen (teg at jklm.no) wrote:
>>>
>>>> On Mon, Oct 20, 2014 at 9:32 PM, Lennart Poettering
>>>> <lennart at poettering.net> wrote:
>>>> > On Tue, 14.10.14 16:19, Jan Synacek (jsynacek at redhat.com) wrote:
>>>> >
>>>> >> https://bugzilla.redhat.com/show_bug.cgi?id=1147248
>>>> >
>>>> > Hmm, so far tmpfiles always adjust access modes, for all types of
>>>> > lines, if that's possible. I think this makes sense. The bug
>>>> > referenced above seems to suggest though that the access mode of the
>>>> > /dev/fuse file node is specified differently in two places
>>>> > though. This sounds like something to fix first?
>>>>
>>>> Well, the /run/tmpfiles.d/kmod.conf one is what the kernel exposes,
>>>> and then the udev rules overrides this. We could surely fix this case,
>>>> but in general I think we should expect that these may differ.
>>>>
>>>> To me it seems that we should not create devices nodes at all, except
>>>> in systemd-tmpfiles-setup-dev.service, the reason being that udev
>>>> rules are only applied to static nodes at udev startup, so any device
>>>> nodes created (or changed) after that may end up with the wrong
>>>> permissions (as seen here).
>>>
>>> Hmm, so does this mean that the kmod tmpfiles converter really should
>>> suffixits lines with the exclamation mark? That way, only invocation
>>> of tmpfiles with --boot would honour those files, which are the ones
>>> we start at boot.
>>>
>>> Does that make sense?
>>
>>
>> Yes, indeed, this is precisely what we want. I had missed that
>> feature. I'll do a patch.
>
>
> And done: <http://permalink.gmane.org/gmane.linux.kernel.modules/1402>.
>
> Jan, does this look like it solves the original problem?
>
> Cheers,
>
> Tom

On my current rawhide (updated today, systemd-216-11.fc22.x86_64), with
kmod patched using the patch you've provided, /dev/fuse is not created,
not even on boot. However, invoking "systemd-tmpfiles.d --create --boot"
correctly creates the node.

# cat /run/tmpfiles.d/kmod.conf 
c! /dev/fuse 0600 - - - 10:229
c! /dev/btrfs-control 0600 - - - 10:234
c! /dev/loop-control 0600 - - - 10:237
d /dev/net 0755 - - -
c! /dev/net/tun 0600 - - - 10:200
c! /dev/ppp 0600 - - - 108:0
c! /dev/uinput 0600 - - - 10:223
c! /dev/uhid 0600 - - - 10:239
d /dev/vfio 0755 - - -
c! /dev/vfio/vfio 0600 - - - 10:196
c! /dev/vhci 0600 - - - 10:137
c! /dev/vhost-net 0600 - - - 10:238
d /dev/snd 0755 - - -
c! /dev/snd/timer 0600 - - - 116:33
d /dev/snd 0755 - - -
c! /dev/snd/seq 0600 - - - 116:1

Is that how it should work?

Cheers,
-- 
Jan Synacek
Software Engineer, Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20141029/410542e9/attachment.sig>


More information about the systemd-devel mailing list