Bug 256658

Summary: ugidfw starts before late mount of nfs causing permissions errors on /var/run/nslcd
Product: Base System Reporter: Dan Langille <dvl>
Component: confAssignee: freebsd-rc (Nobody) <rc>
Status: New ---    
Severity: Affects Some People CC: andrew, grahamperrin
Priority: --- Keywords: regression
Version: 13.0-RELEASE   
Hardware: Any   
OS: Any   

Description Dan Langille freebsd_committer 2021-06-16 19:58:16 UTC
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
Comment 1 andrew 2021-06-17 09:22:06 UTC
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)
Comment 2 Mark Linimon freebsd_committer freebsd_triage 2021-06-17 15:28:15 UTC
^Triage: needs to be examined by someone more familiar with /etc/rc.d/ugidfw than I am.