Interesting permissions difference on NanoBSD build

Karl Denninger karl at denninger.net
Fri Jun 16 12:25:41 UTC 2017


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>


More information about the freebsd-stable mailing list