On 6/16/2017 07:52, Guido Falsi wrote: > On 06/16/17 14:25, Karl Denninger wrote: >> I've recently started playing with the "base" NanoBSD scripts and have >> run into an interesting issue. > [...] >> Note the missing "r" bit for "other" in usr and etc directories -- and >> the missing "x" bit (at minimum) for the root! The same is carried down >> to "local" under usr: >> >> root@NewFS:/pics/Crochet-work-AMD/obj/_.w # ls -al usr >> total 134 >> drwxr-x--x 12 root wheel 12 Jun 15 17:10 . >> drwxr-x--- 18 root wheel 24 Jun 15 17:10 .. >> drwxr-xr-x 2 root wheel 497 Jun 15 17:09 bin >> drwxr-xr-x 52 root wheel 327 Jun 15 17:10 include >> drwxr-xr-x 8 root wheel 655 Jun 15 17:10 lib >> drwxr-xr-x 4 root wheel 670 Jun 15 17:09 lib32 >> drwxr-xr-x 5 root wheel 5 Jun 15 17:10 libdata >> drwxr-xr-x 7 root wheel 70 Jun 15 17:10 libexec >> drwxr-x--x 10 root wheel 11 Jun 15 17:10 local >> drwxr-xr-x 2 root wheel 294 Jun 15 17:08 sbin >> drwxr-xr-x 31 root wheel 31 Jun 15 17:10 share >> drwxr-xr-x 14 root wheel 17 Jun 15 17:10 tests >> root@NewFS:/pics/Crochet-work-AMD/obj/_.w # > I have no idea why this is happening on your system but I'm not > observing it here: > >> ls -al usr > total 85 > drwxr-xr-x 9 root wheel 9 Jun 15 13:32 . > drwxr-xr-x 22 root wheel 29 Jun 15 13:32 .. > drwxr-xr-x 2 root wheel 359 Jun 15 13:32 bin > drwxr-xr-x 4 root wheel 446 Jun 15 13:32 lib > drwxr-xr-x 3 root wheel 3 Jun 15 13:32 libdata > drwxr-xr-x 5 root wheel 47 Jun 15 13:32 libexec > drwxr-xr-x 12 root wheel 13 Jun 15 13:32 local > drwxr-xr-x 2 root wheel 218 Jun 15 13:32 sbin > drwxr-xr-x 17 root wheel 17 Jun 15 13:32 share > > > and I get (almost) the same on the installed nanobsd system: >> ls -al usr > total 24 > drwxr-xr-x 9 root wheel 512 Jun 15 13:32 . > drwxr-xr-x 23 root wheel 512 Jun 15 13:34 .. > drwxr-xr-x 2 root wheel 6144 Jun 15 13:32 bin > drwxr-xr-x 4 root wheel 10752 Jun 15 13:32 lib > drwxr-xr-x 3 root wheel 512 Jun 15 13:32 libdata > drwxr-xr-x 5 root wheel 1024 Jun 15 13:32 libexec > drwxr-xr-x 12 root wheel 512 Jun 15 13:32 local > drwxr-xr-x 2 root wheel 4096 Jun 15 13:32 sbin > drwxr-xr-x 17 root wheel 512 Jun 15 13:32 share > > The machine I'm building the NanoBSD image on is running head r318959, > and is running ZFS, while the NanoBSD system I've built is tracking > 11-STABLE and is at r319971 at present, so a BETA1. > > Could you report version information too? maybe it's a problem present > on head NanoBSD scripts? FreeBSD 11.0-STABLE #15 r312669M: Mon Jan 23 14:01:03 CST 2017 [email protected]:/usr/obj/usr/src/sys/KSD-SMP
I also build using Crochet against both /usr/src (my "primary" source repo, which is on the rev noted here) and against a second one (-HEAD), which I need to use for the RPI3. Neither winds up with this sort of permission issue. The obj directory is on /pics/Crochet-Work-AMD, which is a zfs filesystem mounted off a "scratch" SSD. The problem appears to stem from the creation of "_.w" and since directory permissions are "normally" inherited it promulgates from there unless an explicit permission set occurs. Yet I see nothing that would create the world directory with anything other than the umask at the time it runs. I *am* running this from "batch" -- perhaps that's where the problem is coming from? I'll try adding a "umask 022" to the nanobsd.sh script at the top and see what that does. -- Karl Denninger [email protected] <mailto:[email protected]> /The Market Ticker/ /[S/MIME encrypted email preferred]/
smime.p7s
Description: S/MIME Cryptographic Signature
