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 at 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 at 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 at 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 at 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 at NewFS:/pics/Crochet-work-AMD/obj # mount -o ro /dev/md0s1a /mnt
root at NewFS:/pics/Crochet-work-AMD/obj # cd /mnt
root at 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
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2993 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20170616/b3ed471a/attachment.bin>