This has affect hosts installed with FreeBSD 13 and upgraded from 12 to 13. A summary of the discovery process appears first, followed by the complicating factors which colluded to create the problem. Initial symptom was inability of non-root to use / access Kerberos. With a valid ticket on your laptop, you could ssh to a host where klist should show no valid ticket (we ssh'd in via ssh-keys). $ id dvl id: dvl: no such user $ truss id dvl .... connect(3,{ AF_UNIX "/var/run/nslcd/nslcd.ctl" },26) ERR#13 'Permission denied' .... Permissions on that directory and its contents matched that on 12.x hosts which did not have this issue. An IRC guru suggested: $ sysctl security.mac | grep enabled security.mac.bsdextended.firstmatch_enabled: 1 security.mac.bsdextended.enabled: 1 Looking at bsdextended_script within /etc/rc.conf led to rules which impose restrictions upon /usr/home Let's try: service ugidfw restart id dvl - now works. summary of complicating factors: * /usr/home is mounted by NFS with: foo.example.com:/home /usr/home nfs hard,late,intr,wsize=65536,rsize=65536,port=2049,rw 0 0 * bsdextended_script points to rules which impose restrictions upon /usr/hom * FreeBSD 12 does not show this issue * FreeBSD 13 has this issue * new 13 installs and upgrades from 12 have the same problem * restating ugidfw after boot solves the issue * removing hard,late from NFS did not solve the issue * adding mountlate to the REQUIRES in /etc/rc.d/ugidfw solves the issue
Something that occurs to me is that there might be a use for some way to specify additional dependency order constraints for services in rc.conf to avoid having to modify rc.d files. In the specific case of ugidfw, it's not clear whether putting it after mountlate in the rcorder would be the right fix for all circumstances (though it'd still be a vast improvement over the current case where ugidfw can run at literally any point between FILESYSTEMS and LOGIN). (The "irc guru" referred to in the original report was me)
^Triage: needs to be examined by someone more familiar with /etc/rc.d/ugidfw than I am.
At $WORK we are still manually hacking ugidfw and adding latestart.
Created attachment 243198 [details] Change ugidfw start order Hi, We have same issues with ldap based users. Boot hangs until ldap timeout because ugidfw starts before network Maybe changing REQUIRE: FILESYSTEMS into REQUIRE: NETWORKING is the simplest way to fix this issue. Regards Joris