Re: more default uid/gid for NFS in mountd
On Sun, May 14, 2017 at 01:12:11AM +, Rick Macklem wrote: > >> It is also the case that mountd.c doesn't look "nobody" up in the password > >> database > >> to set the default. It would be nice to do this, but it could result in > >> the mountd daemon > >> getting "stuck" during a boot waiting for an unresponsive LDAP service or > >> similar. > >> Does doing this sound like a good idea? > > > >This is (stuck at boot) already do for case of using NIS and nfsuserd. > There is a difference here. nfsuserd mpas between uid/names, so it can't work > without the password database. > mountd can work without the password database, so I held off on doing this > for now. > > >I am regular see this for case of DNS failed at boot. > >You offer don't impair current behaviour. > As an aside, if you have the critical entries in the local files (/etc/hosts, > /etc/passwd, > /etc/group) and then tell the libraries to search these first in > /etc/nsswitch.conf, then > you usually avoid this problem. Same as for 'nobody' for mountd? > Thanks for the comments, rick > Thanks! ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: more default uid/gid for NFS in mountd
Slawa Olhovchenkov wrote: >Rick Macklem wrote: >> Hi, >> >> Five years ago (yea, it slipped through a crack;-), Slawa reported that files >> created by root would end up owned by uid 2**32-2 (-2 as uint32_t). >> This happens if there is no "-maproot=" in the /etc/exports line. >> >> The cause is obvious. The value is set to -2 by default. >> >> The question is... Should this be changed to 65534 (ie "nobody")? >> - It would seem more consistent to make it the uid of nobody, but I can also >> see >> the argument that since it has been like this *forever*, that changing it >> would be >> a POLA violation. >> What do others think? > >IMHO uid 2**32-2 is POLA violation. >Nobody expect this uid. Too much number. This is like bug. This is what I have just committed. Thanks for the comments. >> It is also the case that mountd.c doesn't look "nobody" up in the password >> database >> to set the default. It would be nice to do this, but it could result in the >> mountd daemon >> getting "stuck" during a boot waiting for an unresponsive LDAP service or >> similar. >> Does doing this sound like a good idea? > >This is (stuck at boot) already do for case of using NIS and nfsuserd. There is a difference here. nfsuserd mpas between uid/names, so it can't work without the password database. mountd can work without the password database, so I held off on doing this for now. >I am regular see this for case of DNS failed at boot. >You offer don't impair current behaviour. As an aside, if you have the critical entries in the local files (/etc/hosts, /etc/passwd, /etc/group) and then tell the libraries to search these first in /etc/nsswitch.conf, then you usually avoid this problem. Thanks for the comments, rick ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: more default uid/gid for NFS in mountd
On 05/08/2017 06:45, Rick Macklem wrote: > Hi, > > Five years ago (yea, it slipped through a crack;-), Slawa reported that files > created by root would end up owned by uid 2**32-2 (-2 as uint32_t). > This happens if there is no "-maproot=" in the /etc/exports line. > > The cause is obvious. The value is set to -2 by default. > > The question is... Should this be changed to 65534 (ie "nobody")? > - It would seem more consistent to make it the uid of nobody, but I can also > see > the argument that since it has been like this *forever*, that changing it > would be > a POLA violation. > What do others think? Since the change is easily communicated in the release notes, I think it seems quite reasonable, especially if you limit it to 12.0. > It is also the case that mountd.c doesn't look "nobody" up in the password > database > to set the default. It would be nice to do this, but it could result in the > mountd daemon > getting "stuck" during a boot waiting for an unresponsive LDAP service or > similar. > Does doing this sound like a good idea? I imagine the lookup could be useful in heterogeneous networks. You might consider adding a CLI flag to mountd to let the admin choose the user by UID/GID, and possibly by username/groupname. That would be a reasonable workaround for networks that often hit the lookup problem. Eric ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: more default uid/gid for NFS in mountd
On Mon, May 08, 2017 at 11:45:46AM +, Rick Macklem wrote: > Hi, > > Five years ago (yea, it slipped through a crack;-), Slawa reported that files > created by root would end up owned by uid 2**32-2 (-2 as uint32_t). > This happens if there is no "-maproot=" in the /etc/exports line. > > The cause is obvious. The value is set to -2 by default. > > The question is... Should this be changed to 65534 (ie "nobody")? > - It would seem more consistent to make it the uid of nobody, but I can also > see > the argument that since it has been like this *forever*, that changing it > would be > a POLA violation. > What do others think? IMHO uid 2**32-2 is POLA violation. Nobody expect this uid. Too much number. This is like bug. > It is also the case that mountd.c doesn't look "nobody" up in the password > database > to set the default. It would be nice to do this, but it could result in the > mountd daemon > getting "stuck" during a boot waiting for an unresponsive LDAP service or > similar. > Does doing this sound like a good idea? This is (stuck at boot) already do for case of using NIS and nfsuserd. I am regular see this for case of DNS failed at boot. You offer don't impair current behaviour. Thanks! > Thanks for any comments, rick > ps: Here's the original email thread, in case you are interested: > > https://lists.freebsd.org/pipermail/freebsd-stable/2012-March/066868.html > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
more default uid/gid for NFS in mountd
Hi, Five years ago (yea, it slipped through a crack;-), Slawa reported that files created by root would end up owned by uid 2**32-2 (-2 as uint32_t). This happens if there is no "-maproot=" in the /etc/exports line. The cause is obvious. The value is set to -2 by default. The question is... Should this be changed to 65534 (ie "nobody")? - It would seem more consistent to make it the uid of nobody, but I can also see the argument that since it has been like this *forever*, that changing it would be a POLA violation. What do others think? It is also the case that mountd.c doesn't look "nobody" up in the password database to set the default. It would be nice to do this, but it could result in the mountd daemon getting "stuck" during a boot waiting for an unresponsive LDAP service or similar. Does doing this sound like a good idea? Thanks for any comments, rick ps: Here's the original email thread, in case you are interested: https://lists.freebsd.org/pipermail/freebsd-stable/2012-March/066868.html ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
