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 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 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
karl at NewFS.denninger.net:/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
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/3aa8cccc/attachment.bin>