I've recently started playing with the "base" NanoBSD scripts and have run into an interesting issue.
Specifically, this is what winds up in the "_.w" (world) directory base when the build completes: root@NewFS:/pics/Crochet-work-AMD/obj/_.w # ls -al total 112 drwxr-x--- 18 root wheel 24 Jun 15 17:10 . drwxr-xr-x 5 root wheel 24 Jun 15 17:11 .. -rw-r--r-- 2 root wheel 955 Jun 15 17:09 .cshrc -rw-r--r-- 2 root wheel 247 Jun 15 17:09 .profile -r--r--r-- 1 root wheel 6197 Jun 15 17:09 COPYRIGHT drwxr-xr-x 2 root wheel 47 Jun 15 17:08 bin drwxr-xr-x 8 root wheel 51 Jun 15 17:09 boot -rw-r--r-- 1 root wheel 12 Jun 15 17:09 boot.config drwxr-xr-x 2 root wheel 2 Jun 15 17:09 cfg drwxr-xr-x 4 root wheel 4 Jun 15 17:10 conf dr-xr-xr-x 2 root wheel 3 Jun 15 17:09 dev drwxr-x--x 28 root wheel 110 Jun 15 17:10 etc drwxr-xr-x 4 root wheel 56 Jun 15 17:08 lib drwxr-xr-x 3 root wheel 5 Jun 15 17:09 libexec drwxr-xr-x 2 root wheel 2 Jun 15 17:07 media drwxr-xr-x 2 root wheel 2 Jun 15 17:07 mnt dr-xr-xr-x 2 root wheel 2 Jun 15 17:07 proc drwxr-xr-x 2 root wheel 146 Jun 15 17:08 rescue drwxr-xr-x 2 root wheel 12 Jun 15 17:10 root drwxr-xr-x 2 root wheel 137 Jun 15 17:08 sbin lrwxr-xr-x 1 root wheel 11 Jun 15 17:07 sys -> usr/src/sys lrwxr-xr-x 1 root wheel 7 Jun 15 17:10 tmp -> var/tmp drwxr-x--x 12 root wheel 12 Jun 15 17:10 usr drwxr-xr-x 25 root wheel 25 Jun 15 17:10 var root@NewFS:/pics/Crochet-work-AMD/obj/_.w # 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 do not know if this is intentional, but it certainly was not expected. It does carry through to the disk image that is created as well and then there's this, which if you mount the image leads me to wonder what's going on: root@NewFS:/pics/Crochet-work-AMD/obj # mount -o ro /dev/md0s1a /mnt root@NewFS:/pics/Crochet-work-AMD/obj # cd /mnt root@NewFS:/mnt # ls -al total 34 drwxr-x--- 19 root wheel 512 Jun 15 17:10 . drwxr-xr-x 45 root wheel 55 Jun 1 10:58 .. -rw-r--r-- 2 root wheel 955 Jun 15 17:09 .cshrc -rw-r--r-- 2 root wheel 247 Jun 15 17:09 .profile drwxrwxr-x 2 root operator 512 Jun 15 17:10 .snap -r--r--r-- 1 root wheel 6197 Jun 15 17:09 COPYRIGHT drwxr-xr-x 2 root wheel 1024 Jun 15 17:08 bin drwxr-xr-x 8 root wheel 1024 Jun 15 17:09 boot -rw-r--r-- 1 root wheel 12 Jun 15 17:09 boot.config drwxr-xr-x 2 root wheel 512 Jun 15 17:09 cfg drwxr-xr-x 4 root wheel 512 Jun 15 17:10 conf dr-xr-xr-x 2 root wheel 512 Jun 15 17:09 dev drwxr-x--x 28 root wheel 2048 Jun 15 17:10 etc drwxr-xr-x 4 root wheel 1536 Jun 15 17:08 lib drwxr-xr-x 3 root wheel 512 Jun 15 17:09 libexec drwxr-xr-x 2 root wheel 512 Jun 15 17:07 media drwxr-xr-x 2 root wheel 512 Jun 15 17:07 mnt dr-xr-xr-x 2 root wheel 512 Jun 15 17:07 proc drwxr-xr-x 2 root wheel 2560 Jun 15 17:08 rescue drwxr-xr-x 2 root wheel 512 Jun 15 17:10 root drwxr-xr-x 2 root wheel 2560 Jun 15 17:08 sbin lrwxr-xr-x 1 root wheel 11 Jun 15 17:07 sys -> usr/src/sys lrwxr-xr-x 1 root wheel 7 Jun 15 17:10 tmp -> var/tmp drwxr-x--x 12 root wheel 512 Jun 15 17:10 usr drwxr-xr-x 25 root wheel 512 Jun 15 17:10 var Note the permissions at the root -- that denies *search* for others.... it is an exact copy of the "_.w" permission list of course, but if you create a non-root user as a part of the NanoBSD build you wind up with some "interesting" behavior when that user logs in! I'm assuming this is unintentional but wondering where it comes from (and whether it needs / should be fixed); it's easy to fix it, of course, once the embedded system boots but you need to (obviously) mount read/write long enough to update it.... -- Karl Denninger [email protected] <mailto:[email protected]> /The Market Ticker/ /[S/MIME encrypted email preferred]/
smime.p7s
Description: S/MIME Cryptographic Signature
