/dev/net/tun no longer exists in F31 rawhide ?

[Daniel P. Berrangé]

Historically in Fedora the /dev/net/tun device always existed, even if
there is no 'tun' module currently loaded. Opening it then cause the
'tun' kernel module to autoload IIUC.

In Fedora 31 rawhide this is no longer the case. The /dev/net/tun device
node doesn't exist at all in a fresh install.

Libvirt has always assumed the historical behaviour so currently it fails
to setup networking due to /dev/net/tun no longer existing.

I expect other applications which deal with tun devices will be similarly
affected.

I'm wondering if anyone can explain whether this is an intentional change
in setup of /dev/ in Fedora 31 rawhide, or whether it is a bug that needs
to be fixed ?  I'm struggling to figure out what changed - presumably
something related to udev but the rules wrt /dev/net/tun appear the same
in F30 and F31.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

[Adam Williamson]

On Mon, 2019-03-18 at 14:07 +0000, Daniel P. Berrangé wrote:
>  Historically in Fedora the /dev/net/tun device always existed, even
> if
>  there is no 'tun' module currently loaded. Opening it then cause the
>  'tun' kernel module to autoload IIUC.
>  
>  In Fedora 31 rawhide this is no longer the case. The /dev/net/tun device
>  node doesn't exist at all in a fresh install.
>  
>  Libvirt has always assumed the historical behaviour so currently it fails
>  to setup networking due to /dev/net/tun no longer existing.
>  
>  I expect other applications which deal with tun devices will be similarly
>  affected.
>  
>  I'm wondering if anyone can explain whether this is an intentional change
>  in setup of /dev/ in Fedora 31 rawhide, or whether it is a bug that needs
>  to be fixed ?  I'm struggling to figure out what changed - presumably
>  something related to udev but the rules wrt /dev/net/tun appear the same
>  in F30 and F31. 
I'd guess it's most likely a kernel change, so ask laura / justin
maybe?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Peter Robinson]

On Mon, Mar 18, 2019 at 2:23 PM Adam Williamson
<adamwill(a)fedoraproject.org&gt; wrote:
>  On Mon, 2019-03-18 at 14:07 +0000, Daniel P. Berrangé wrote:
>  > Historically in Fedora the /dev/net/tun device always existed, even if
>  > there is no 'tun' module currently loaded. Opening it then cause the
>  > 'tun' kernel module to autoload IIUC.
>  >
>  > In Fedora 31 rawhide this is no longer the case. The /dev/net/tun device
>  > node doesn't exist at all in a fresh install.
>  >
>  > Libvirt has always assumed the historical behaviour so currently it fails
>  > to setup networking due to /dev/net/tun no longer existing.
>  >
>  > I expect other applications which deal with tun devices will be similarly
>  > affected.
>  >
>  > I'm wondering if anyone can explain whether this is an intentional change
>  > in setup of /dev/ in Fedora 31 rawhide, or whether it is a bug that needs
>  > to be fixed ?  I'm struggling to figure out what changed - presumably
>  > something related to udev but the rules wrt /dev/net/tun appear the same
>  > in F30 and F31.
>
>  I'd guess it's most likely a kernel change, so ask laura / justin
>  maybe? 
I would have guessed at udev change as the kernel doesn't make /dev anything.

[Tom Hughes]

On 18/03/2019 14:07, Daniel P. Berrangé wrote:

>  Historically in Fedora the /dev/net/tun device always existed, even
> if
>  there is no 'tun' module currently loaded. Opening it then cause the
>  'tun' kernel module to autoload IIUC. 
It doesn't just exist..

There is a systemd service (kmod-static-nodes.service) which runs
at boot and generates:

   /run/tmpfiles.d/kmod.conf

Which is then processed by systemd-tmpfiles-setup-dev.service to
create the device nodes.

The actual list comes from "/usr/bin/kmod static-nodes" which
uses the devname and char-major aliases in the module to decide
what device nodes to create.

Tom

-- 
Tom Hughes (tom(a)compton.nu)
http://compton.nu/

[Daniel P. Berrangé]

On Mon, Mar 18, 2019 at 02:23:12PM +0000, Tom Hughes wrote:
>  On 18/03/2019 14:07, Daniel P. Berrangé wrote:
>  
>  > Historically in Fedora the /dev/net/tun device always existed, even if
>  > there is no 'tun' module currently loaded. Opening it then cause the
>  > 'tun' kernel module to autoload IIUC.
>  
>  It doesn't just exist..
>  
>  There is a systemd service (kmod-static-nodes.service) which runs
>  at boot and generates:
>  
>    /run/tmpfiles.d/kmod.conf
>  
>  Which is then processed by systemd-tmpfiles-setup-dev.service to
>  create the device nodes.
>  
>  The actual list comes from "/usr/bin/kmod static-nodes" which
>  uses the devname and char-major aliases in the module to decide
>  what device nodes to create. 
Ah, that's useful info. It seems kmod-static-nodes.service failed to
run

Condition: start condition failed at Mon 2019-03-18 14:29:38 GMT; 2s ago
           └─
ConditionFileNotEmpty=/lib/modules/5.1.0-0.rc0.git9.1.fc31.x86_64/modules.devname was not
met


The file does in fact exist, but SELinux is blocking access to it.

  type=AVC msg=audit(1552919426.997:335): avc:  denied  { getattr } for  pid=1
comm="systemd"
path="/usr/lib/modules/5.1.0-0.rc0.git9.1.fc31.x86_64/modules.devname"
dev="dm-0" ino=753068 scontext=system_u:system_r:init_t:s0
tcontext=unconfined_u:object_r:modules_dep_t:s0 tclass=file permissive=1


Setting permissive mode fixes this. It appears there's a policy change in
this area, since the file has modules_dep_t in F31, but modules_object_t
in F30.

I'll file a bug against SELinux policy for this.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

[Daniel P. Berrangé]

On Mon, Mar 18, 2019 at 02:33:20PM +0000, Daniel P. Berrangé wrote:
>  On Mon, Mar 18, 2019 at 02:23:12PM +0000, Tom Hughes wrote:
>  > On 18/03/2019 14:07, Daniel P. Berrangé wrote:
>  > 
>  > > Historically in Fedora the /dev/net/tun device always existed, even if
>  > > there is no 'tun' module currently loaded. Opening it then cause the
>  > > 'tun' kernel module to autoload IIUC.
>  > 
>  > It doesn't just exist..
>  > 
>  > There is a systemd service (kmod-static-nodes.service) which runs
>  > at boot and generates:
>  > 
>  >   /run/tmpfiles.d/kmod.conf
>  > 
>  > Which is then processed by systemd-tmpfiles-setup-dev.service to
>  > create the device nodes.
>  > 
>  > The actual list comes from "/usr/bin/kmod static-nodes" which
>  > uses the devname and char-major aliases in the module to decide
>  > what device nodes to create.
>  
>  Ah, that's useful info. It seems kmod-static-nodes.service failed to
>  run
>  
>  Condition: start condition failed at Mon 2019-03-18 14:29:38 GMT; 2s ago
>             └─
> ConditionFileNotEmpty=/lib/modules/5.1.0-0.rc0.git9.1.fc31.x86_64/modules.devname was not
> met
>  
>  
>  The file does in fact exist, but SELinux is blocking access to it.
>  
>    type=AVC msg=audit(1552919426.997:335): avc:  denied  { getattr } for  pid=1
> comm="systemd"
> path="/usr/lib/modules/5.1.0-0.rc0.git9.1.fc31.x86_64/modules.devname"
> dev="dm-0" ino=753068 scontext=system_u:system_r:init_t:s0
> tcontext=unconfined_u:object_r:modules_dep_t:s0 tclass=file permissive=1
>  
>  
>  Setting permissive mode fixes this. It appears there's a policy change in
>  this area, since the file has modules_dep_t in F31, but modules_object_t
>  in F30.
>  
>  I'll file a bug against SELinux policy for this. 
  https://bugzilla.redhat.com/show_bug.cgi?id=1689975


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|