Date: Sun, 9 Jul 2017 19:57:22 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: "freebsd-current@freebsd.org" <freebsd-current@freebsd.org> Cc: "rc@freebsd.org" <rc@freebsd.org> Subject: small patch for /etc/rc.d/nfsd, bugfix or POLA violation? Message-ID: <YTXPR01MB0189F5614497D4FA96A7579ADDA80@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM>
next in thread | raw e-mail | index | archive | help
--_002_YTXPR01MB0189F5614497D4FA96A7579ADDA80YTXPR01MB0189CANP_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi,
The attached one line patch to /etc/rc.d/nfsd modifies the script so that i=
t
does not force the nfsuserd to be run when nfsv4_server_enable is set.
(nfsuserd can still be enabled via nfsuserd_enable=3D"YES" is /etc/rc.conf.=
)
Here's why I think this patch might be appropriate...
(a) - The original RFC for NFSv4 (RFC3530) essentially required Owners and
Owner_groups to be specified as <user>@<domain> and this required
the nfsuserd daemon to be running.
(b) - RFC7530, which replace RFC3530, allows a Owner/Owner_group string to =
be
the uid/gid number in a string when using AUTH_SYS. This simplifies confi=
guration
for an all AUTH_SYS/POSIX environment (most NFS uses, I suspect?).
To make the server do (b), two things need to be done:
1 - set vfs.nfsd.enable_stringtouid=3D1
2 - set vfs.nfsd.enable_uidtostring=3D1 (for head, I don't know if it will =
be MFC'd?)
OR
- never run nfsuserd after booting (killing it off after it has been runn=
ing is not
sufficient)
=20
Given the above, it would seem that /etc/rc.d/nfsd should not force running=
of
the nfsuserd daemon, due to changes in the protocol.
However, this will result in a POLA violation, in that after the patch, nfs=
userd won't
start when booting, unless nfsuserd_enable=3D"YES" is added to /etc/rc.conf=
.
So, what do people think about this patch? rick=
--_002_YTXPR01MB0189F5614497D4FA96A7579ADDA80YTXPR01MB0189CANP_
Content-Type: application/octet-stream; name="nfsd-rcd.patch"
Content-Description: nfsd-rcd.patch
Content-Disposition: attachment; filename="nfsd-rcd.patch"; size=372;
creation-date="Sun, 09 Jul 2017 19:57:16 GMT";
modification-date="Sun, 09 Jul 2017 19:57:16 GMT"
Content-Transfer-Encoding: base64
LS0tIG5mc2Quc2F2CTIwMTctMDctMDkgMTU6MzM6MDguNDE2MzgzMDAwIC0wNDAwCisrKyBuZnNk
CTIwMTctMDctMDkgMTU6MzM6NDIuNTc3MDU3MDAwIC0wNDAwCkBAIC0zMyw4ICszMyw3IEBAIG5m
c2RfcHJlY21kKCkKIAkJc3lzY3RsIHZmcy5uZnNkLm5mc19wcml2cG9ydD0wID4gL2Rldi9udWxs
CiAJZmkKIAotCWlmIGNoZWNreWVzbm8gbmZzdjRfc2VydmVyX2VuYWJsZSB8fCBcCi0JICAgIGNo
ZWNreWVzbm8gbmZzX3NlcnZlcl9tYW5hZ2VnaWRzOyB0aGVuCisJaWYgY2hlY2t5ZXNubyBuZnNf
c2VydmVyX21hbmFnZWdpZHM7IHRoZW4KIAkJZm9yY2VfZGVwZW5kIG5mc3VzZXJkIHx8IGVyciAx
ICJDYW5ub3QgcnVuIG5mc3VzZXJkIgogCWZpCiAK
--_002_YTXPR01MB0189F5614497D4FA96A7579ADDA80YTXPR01MB0189CANP_--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTXPR01MB0189F5614497D4FA96A7579ADDA80>