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: Really weird behavior with terminals/sessions in past couple weeks
On Sat, 13 May 2017, Ngie Cooper (yaneurabeya) wrote: On May 13, 2017, at 11:05, Ngie Cooper (yaneurabeya) wrote: On May 13, 2017, at 11:01, Ngie Cooper (yaneurabeya) wrote: Hi, I???ve been noticing some really weird behavior with terminal input after updating my kernel/userland ??? in particular, if I do `arc diff ???create` (which opens vi/vim), and try to do edits/use ^c, it will terminate the running process for `arc diff ???create`. Similarly, I was seeing really weird input via vim (when doing `svn ci`) where if I had one of the editing modes on, like insert, it would delete several lines at once; I worked around this by using ^c to terminate insert mode, but that???s a really bad hack. It worked ok with r316745, got worse in r317727, and doesn???t seem to be any better in r318250. I forgot to mention: I???m using SSH to access my machine. My gut feeling is the sc(4) commits might have tickled or introduced some bugs. I???ll try reverting the following commits over the next couple days to see whether or not my experience improves: r316827 r316830 r316865 r316878 r316974 r316977 r317190 r317198 r317199 r317245 r317256 r317264. I don't think I touched anything related to editing. Certainly not for fixing the mouse cursor starting some time before r317827. Since then I have spent too much time on mouse cursors and not much else. Bruce___ 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: Really weird behavior with terminals/sessions in past couple weeks
> On May 13, 2017, at 11:05, Ngie Cooper (yaneurabeya) > wrote: > > >> On May 13, 2017, at 11:01, Ngie Cooper (yaneurabeya) >> wrote: >> >> Hi, >> I’ve been noticing some really weird behavior with terminal input after >> updating my kernel/userland — in particular, if I do `arc diff —create` >> (which opens vi/vim), and try to do edits/use ^c, it will terminate the >> running process for `arc diff —create`. Similarly, I was seeing really weird >> input via vim (when doing `svn ci`) where if I had one of the editing modes >> on, like insert, it would delete several lines at once; I worked around this >> by using ^c to terminate insert mode, but that’s a really bad hack. It >> worked ok with r316745, got worse in r317727, and doesn’t seem to be any >> better in r318250. > > I forgot to mention: I’m using SSH to access my machine. My gut feeling is the sc(4) commits might have tickled or introduced some bugs. I’ll try reverting the following commits over the next couple days to see whether or not my experience improves: r316827 r316830 r316865 r316878 r316974 r316977 r317190 r317198 r317199 r317245 r317256 r317264. Thanks, -Ngie signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Really weird behavior with terminals/sessions in past couple weeks
> On May 13, 2017, at 11:01, Ngie Cooper (yaneurabeya) > wrote: > > Hi, > I’ve been noticing some really weird behavior with terminal input after > updating my kernel/userland — in particular, if I do `arc diff —create` > (which opens vi/vim), and try to do edits/use ^c, it will terminate the > running process for `arc diff —create`. Similarly, I was seeing really weird > input via vim (when doing `svn ci`) where if I had one of the editing modes > on, like insert, it would delete several lines at once; I worked around this > by using ^c to terminate insert mode, but that’s a really bad hack. It worked > ok with r316745, got worse in r317727, and doesn’t seem to be any better in > r318250. I forgot to mention: I’m using SSH to access my machine. -Ngie signature.asc Description: Message signed with OpenPGP using GPGMail
Really weird behavior with terminals/sessions in past couple weeks
Hi, I’ve been noticing some really weird behavior with terminal input after updating my kernel/userland — in particular, if I do `arc diff —create` (which opens vi/vim), and try to do edits/use ^c, it will terminate the running process for `arc diff —create`. Similarly, I was seeing really weird input via vim (when doing `svn ci`) where if I had one of the editing modes on, like insert, it would delete several lines at once; I worked around this by using ^c to terminate insert mode, but that’s a really bad hack. It worked ok with r316745, got worse in r317727, and doesn’t seem to be any better in r318250. Thanks, -Ngie signature.asc Description: Message signed with OpenPGP using GPGMail
