mtimc
Posts: 2
Joined: Thu Jul 12, 2012 4:25 pm

pxe / netboot challenges

Thu May 17, 2018 4:18 pm

I'm trying to get the pxe booting process working (http://bit.ly/2Iu1wp2). All seems fine, although I'm using a fedora nfs server - which means enabling nfs over udp. I'm not clear why the dhcp option 43 is required - it doesn't seem to be required.

However, thus far I've encountered a few niggles, most particularly:
- since nfs doesn't support extended attributes (I believe that's the cause), network related programs in particular do not work for ordinary users.

Thus on a pxe booted pi:
```
$> ping 8.8.8.8
ping: socket: Operation not permitted
$> getcap /bin/ping
Failed to get capabilities of file `/bin/ping' (Operation not supported)
```
Whereas on a pi booted from the 'same' SDCard image:
```
$> ping -c 1 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=61 time=24.4 ms

--- 8.8.8.8 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
$> getcap /bin/ping
/bin/ping = cap_net_raw+ep
```
Has anyone else encountered this, or is it a function of my setup?

asavah
Posts: 346
Joined: Thu Aug 14, 2014 12:49 am

Re: pxe / netboot challenges

Thu May 17, 2018 4:51 pm

Yep, this is known, there is no support for extended attributes (xattr) in NFS.

mfa298
Posts: 1273
Joined: Tue Apr 22, 2014 11:18 am

Re: pxe / netboot challenges

Fri May 18, 2018 9:29 am

mtimc wrote:
Thu May 17, 2018 4:18 pm
However, thus far I've encountered a few niggles, most particularly:
- since nfs doesn't support extended attributes (I believe that's the cause), network related programs in particular do not work for ordinary users.

Thus on a pxe booted pi:
```
$> ping 8.8.8.8
ping: socket: Operation not permitted
$> getcap /bin/ping
Failed to get capabilities of file `/bin/ping' (Operation not supported)
...
Has anyone else encountered this, or is it a function of my setup?
I suspect it's an issue with the setup of your NFS server. By default NFS will squash the root user so they'll appear as nobody instead of root. Certain tools (ping, sudo, su) require extra permissions so have the suid bit set meaning they get run as the user that owns the program rather than the logged in user.

Looking at my SD booted Pi.

Code: Select all

[email protected]:~ $ ls -l /bin/ping
-rwsr-xr-x 1 root root 55720 Nov 10  2016 /bin/ping
[email protected]:~ $ getcap -v /bin/ping
/bin/ping
[email protected]:~ $ 
That shows the ownership you should see for /bin/ping - I suspect on your NFS mounted setup it's showing user nobody rather than user root.

With NFS4 there are actually two things that might effect what the users look like. The first is the root squashing (as above) the second is the id mapping service. This attempts to match user names on the client to usernames on the server rather than just working on UIDs. For the ID mapping service both the client and server need to think they're in the same domain.

mtimc
Posts: 2
Joined: Thu Jul 12, 2012 4:25 pm

Re: pxe / netboot challenges

Mon May 21, 2018 10:11 am

Is there an official workaround/proposed fix for non-support of xattrs in nfs? (eg fixup the permissions on the source filesystem, add xattrs via sidecar files), or is this just a bump in the road for pxe booted pi's?

I can confirm that both the file on the nfs host and as see by the nfs client is owned by root and has no setuid bits:

as seen by client:
`
ll tmp/bin/ping
-rwxr-xr-x 1 root root 55720 Nov 10 2016 tmp/bin/ping
`

As seen on nfs server:
`
ll mnt2/bin/ping
-rwxr-xr-x 1 root root 55720 Nov 10 2016 mnt2/bin/ping
`

tc

ShiftPlusOne
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5240
Joined: Fri Jul 29, 2011 5:36 pm
Location: The unfashionable end of the western spiral arm of the Galaxy

Re: pxe / netboot challenges

Mon May 21, 2018 11:06 am

How this is handled in Debian:
If setcap cap_net_raw+ep /bin/ping fails, then run chmod u+s /bin/ping, which will automatically run it as root each time.

mfa298
Posts: 1273
Joined: Tue Apr 22, 2014 11:18 am

Re: pxe / netboot challenges

Mon May 21, 2018 12:16 pm

mtimc wrote:
Mon May 21, 2018 10:11 am
Is there an official workaround/proposed fix for non-support of xattrs in nfs? (eg fixup the permissions on the source filesystem, add xattrs via sidecar files), or is this just a bump in the road for pxe booted pi's?

I can confirm that both the file on the nfs host and as see by the nfs client is owned by root and has no setuid bits:
I wonder if this is related to how you created your netboot image (did what you copied the source from get mounted nosuid perhaps?)

I just netbooted my Pi3B+ to see what that shows:

Code: Select all

[email protected]:~$ mount
192.168.1.2:/export/netboot/algol on / type nfs (rw,relatime,vers=2,rsize=4096,wsize=4096,namlen=255,hard,nolock,proto=udp,timeo=11,retrans=3,sec=sys,mountaddr=192.168.1.2,mountvers=1,mountproto=udp,local_lock=all,addr=192.168.1.2)
[email protected]:~$ ping -c 1 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=59 time=33.3 ms

--- 8.8.8.8 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 33.339/33.339/33.339/0.000 ms
[email protected]:~$ ls -l /bin/ping
-rwsr-xr-x 1 root root 55720 Nov 10  2016 /bin/ping
And Looking at the server (SmartOS with the fs on ZFS)

Code: Select all

[[email protected] /export/netboot]# ls -l raspbian-lite/bin/ping
-rwsr-xr-x   1 root     root       55720 Nov 10  2016 raspbian-lite/bin/ping
[[email protected] /export/netboot]# ls -l algol/bin/ping
-rwsr-xr-x   1 root     root       55720 Nov 10  2016 algol/bin/ping
The raspbian-lite folder is a straight rsync from a downloaded image 2018-03-13 (mounted on Fedora 27 and rsynced over the network) from which a snapshot and clone was made for algol

Code: Select all

[[email protected] /export/netboot]# zfs get origin /export/netboot/algol
NAME                PROPERTY  VALUE                                          SOURCE
data/netboot/algol  origin    data/netboot/[email protected]  -
Looking at my image (server side) the following files look to be suid

Code: Select all

[[email protected] /export/netboot/algol]# find . -perm -4000 -ls
 7525   88 -rwsr-xr-x   1 root     root        88508 Mar 20  2017 ./sbin/mount.nfs
 7524   36 -rwsr-xr-x   1 root     root        34640 Mar  8  2017 ./sbin/mount.cifs
12913  524 -rwsr-xr-x   1 root     root       439952 Mar  1 15:17 ./usr/lib/openssh/ssh-keysign
12917   18 -rwsr-xr-x   1 root     root        14032 May 24  2017 ./usr/lib/policykit-1/polkit-agent-helper-1
12465   36 -rwsr-xr--   1 root     109         34248 Mar  2 08:59 ./usr/lib/dbus-1.0/dbus-daemon-launch-helper
 8076  268 -rwsr-xr-x   1 root     root       135376 Jun  5  2017 ./usr/bin/sudo
 7933   36 -rwsr-xr-x   1 root     root        30900 May 17  2017 ./usr/bin/newgrp
 7705   36 -rwsr-xr-x   1 root     root        31452 May 17  2017 ./usr/bin/chsh
 7827   59 -rwsr-xr-x   1 root     root        57820 May 17  2017 ./usr/bin/gpasswd
 7703   41 -rwsr-xr-x   1 root     root        40324 May 17  2017 ./usr/bin/chfn
 7966   24 -rwsr-xr-x   1 root     root        18288 May 24  2017 ./usr/bin/pkexec
 7947   47 -rwsr-xr-x   1 root     root        45648 May 17  2017 ./usr/bin/passwd
 1075   36 -rwsr-xr-x   1 root     root        34872 Mar  7 18:29 ./bin/mount
 1118   24 -rwsr-xr-x   1 root     root        22436 Mar  7 18:29 ./bin/umount
 1100   36 -rwsr-xr-x   1 root     root        31016 May 17  2017 ./bin/su
 1085   59 -rwsr-xr-x   1 root     root        55720 Nov 10  2016 ./bin/ping
This also matches looking on the client.

Return to “Advanced users”

Who is online

Users browsing this forum: DirkS, thagrol and 15 guests