Date: Fri, 16 Jun 2017 09:55:35 -0500 From: Karl Denninger <karl@denninger.net> To: freebsd-stable@freebsd.org Subject: Re: Interesting permissions difference on NanoBSD build Message-ID: <129b610a-0f2b-4831-ea5f-9aa4c323cfa8@denninger.net> In-Reply-To: <0561597d-4b24-f68e-33a8-d0902e7696da@denninger.net> References: <a6e9db4f-235e-bd40-e361-a8af84a68186@denninger.net> <1387791f-fe22-08d7-2048-26bd95eab451@madpilot.net> <0561597d-4b24-f68e-33a8-d0902e7696da@denninger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
On 6/16/2017 08:21, Karl Denninger wrote:
> 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
> karl@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.
Nope.
It's something in the installworld subset; I put a stop in after the
clean/create world directory and I have a 0755 permission mask on the
(empty) directory.
Hmmm...
I do not know where this is coming from now but this test implies that
it's the "installworld" action that causes it.
root@NewFS:/pics/Crochet-work-AMD/obj # ls -al
total 2176760
drwxr-xr-x 5 root wheel 24 Jun 16 09:41 .
drwxr-xr-x 3 root wheel 3 Jun 16 08:25 ..
-rw-r--r-- 1 root wheel 7658918 Jun 16 09:22 _.bk
-rw-r--r-- 1 root wheel 53768368 Jun 16 09:15 _.bw
-rw-r--r-- 1 root wheel 200 Jun 16 09:25 _.cust.cust_comconsole
-rw-r--r-- 1 root wheel 733 Jun 16 09:25 _.cust.cust_freebsd
-rw-r--r-- 1 root wheel 550 Jun 16 09:25 _.cust.cust_install_files
-rw-r--r-- 1 root wheel 16958 Jun 16 09:25 _.cust.cust_pkgng
-rw-r--r-- 1 root wheel 2566610 Jun 16 09:26 _.di
-rw-r--r-- 1 root wheel 6000000000 Jun 16 09:26 _.disk.full
-rw-r--r-- 1 root wheel 2711020032 Jun 16 09:26 _.disk.image
-rw-r--r-- 1 root wheel 59 Jun 16 09:25 _.dl
-rw-r--r-- 1 root wheel 59521 Jun 16 09:25 _.du
-rw-r--r-- 1 root wheel 2041 Jun 16 08:25 _.env
-rw-r--r-- 1 root wheel 75783 Jun 16 09:24 _.etc
-rw-r--r-- 1 root wheel 148 Jun 16 09:25 _.fdisk
-rw-r--r-- 1 root wheel 215692 Jun 16 09:25 _.ik
-rw-r--r-- 1 root wheel 4085907 Jun 16 09:24 _.iw
drwxr-xr-x 2 root wheel 2 Jun 16 09:25 _.mnt
-rw-r--r-- 1 root wheel 2676015 Jun 16 09:25 _.mtree
drwxr-xr-x 2 root wheel 2 Jun 16 09:41 _.w
-rw-r--r-- 1 root wheel 22 Jun 16 08:25 make.conf.build
-rw-r--r-- 1 root wheel 22 Jun 16 09:22 make.conf.install
drwxr-xr-x 3 root wheel 3 Jun 16 08:25 usr
root@NewFS:/usr/src/tools/tools/nanobsd # sh nanobsd.sh -b -n -c
PCEngines.conf
00:00:00 ### Exporting NanoBSD variables
00:00:00 ### Setting variable: MAKEOBJDIRPREFIX="/pics/Crochet-work-AMD/obj"
00:00:00 ### Setting variable: NANO_ARCH="amd64"
00:00:00 ### Setting variable: NANO_CODESIZE="0"
00:00:00 ### Setting variable: NANO_CONFSIZE="125000"
00:00:00 ### Setting variable: NANO_CUSTOMIZE=" cust_comconsole
cust_pkgng cust_install_files cust_freebsd"
00:00:00 ### Setting variable: NANO_DATASIZE="1000000"
00:00:00 ### Setting variable: NANO_DRIVE="mmcsd0"
00:00:00 ### Setting variable: NANO_HEADS="16"
00:00:00 ### Setting variable: NANO_IMAGES="2"
00:00:00 ### Setting variable: NANO_IMGNAME="_.disk.full"
00:00:00 ### Setting variable: NANO_MAKE="make"
00:00:00 ### Setting variable:
NANO_MAKE_CONF_BUILD="/pics/Crochet-work-AMD/obj/make.conf.build"
00:00:00 ### Setting variable:
NANO_MAKE_CONF_INSTALL="/pics/Crochet-work-AMD/obj/make.conf.install"
00:00:00 ### Setting variable: NANO_MEDIASIZE="11718750"
00:00:00 ### Setting variable: NANO_NAME="pcengines"
00:00:00 ### Setting variable: NANO_NEWFS="-b 4096 -f 512 -i 8192 -U"
00:00:00 ### Setting variable: NANO_OBJ="/pics/Crochet-work-AMD/obj"
00:00:00 ### Setting variable: NANO_PMAKE="make -j 8"
00:00:00 ### Setting variable: NANO_SECTS="63"
00:00:00 ### Setting variable: NANO_SRC="/usr/src"
00:00:00 ### Setting variable: NANO_TOOLS="/usr/src/tools/tools/nanobsd"
00:00:00 ### Setting variable:
NANO_WORLDDIR="/pics/Crochet-work-AMD/obj/_.w"
00:00:00 ### Setting variable: NANO_BOOT0CFG="-o packet -s 1 -m 3"
00:00:00 ### Setting variable: NANO_BOOTLOADER="boot/boot0sio"
00:00:00 ### Setting variable: NANO_LABEL=""
00:00:00 ### Setting variable: NANO_MODULES="default"
00:00:00 ### Setting variable: NANO_NOPRIV_BUILD=""
00:00:00 ### Setting variable: NANO_METALOG=""
00:00:00 ### Setting variable: NANO_LOG="/pics/Crochet-work-AMD/obj"
00:00:00 ### Setting variable: SRCCONF="/dev/null"
00:00:00 ### Setting variable: SRC_ENV_CONF="/dev/null"
00:00:00 # NanoBSD image pcengines build starting
00:00:00 ## run early customize scripts
00:00:00 ## Skipping buildworld (as instructed)
00:00:00 ## Skipping buildkernel (as instructed)
00:00:00 ## Clean and create world directory
(/pics/Crochet-work-AMD/obj/_.w)
STOP STOP STOP
--
Karl Denninger
karl@denninger.net <mailto:karl@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
[-- Attachment #2 --]
0 *H
010
`He 0 *H
\0X0@=0
*H
01 0 UUS10UFlorida10U Niceville10U
Cuda Systems LLC1 0UCuda Systems LLC CA1"0 *H
Cuda Systems LLC CA0
161218194535Z
211217194535Z0W1 0 UUS10UFlorida10U
Cuda Systems LLC10Ukarl@denninger.net0"0
*H
0
͍fd`1ie6";fSz`5¹/?{=Ӵowj ħ_fnӴMG\ҢҖ4ib}>@mJo&m M;
Q9U cj] p퐆W.2E=
^¢tzĄ'5i7_ `~#dY
`]R]N%R}EXzqV@[oN T>5AwYˡA "\v&YG]+($p:M,T?=mJkMљg*ym
L! J[./d?W^LysD'1
+V'~{-SSX = q-f=%&V<m4 BeSet|
l2m 6iO{wv
+ aH Xˈ5=~é*C!?uJr3tb' 3`Oe)üLxt&3N526 llU
.|Cp[l? 007++0)0'+0http://cudasystems.net:88880 U 0 0 `HB0 U 0, `HB
OpenSSL Generated Certificate0 U /Zi
0GhG0 U #0$q}ݽʒm50 U 0karl@denninger.net0
*H
b% X% gwq
Ɂэr K[DMJ35W6
sz8d|qB2Cyw2PbV}
â[!W{HD7oD.TZ'w6~g( -,]R8P{*[f<1=7 jGj9铚~3f2AʺN k~@vz^j(>ͺyh2y { /9}4.45#S|<fW!.,Bss*Q+h =}l@ "q "M&6J5*,G {hɫjbNgǠ.ЃXȶ4$O.5evHlZba!4eE!x|Za1nZ5TuPvW|#G+ DZpI7S'n0 haGa@vZ e|]Cu+))vRyY10001 0 UUS10UFlorida10U Niceville10U
Cuda Systems LLC1 0UCuda Systems LLC CA1"0 *H
Cuda Systems LLC CA=0
`He M0 *H
1 *H
0 *H
1
170616145535Z0O *H
1B@Yy|GX:t xeGG YO L&9NG~}jxZ0l *H
1_0]0 `He*0 `He0
*H
0*H
0
*H
@0+0
*H
(0 +71001 0 UUS10UFlorida10U Niceville10U
Cuda Systems LLC1 0UCuda Systems LLC CA1"0 *H
Cuda Systems LLC CA=0 *H
101 0 UUS10UFlorida10U Niceville10U
Cuda Systems LLC1 0UCuda Systems LLC CA1"0 *H
Cuda Systems LLC CA=0
*H
+J{8eF+y+T-`%VHt $ӪqAc vXscI,og$huȃ)"Ԕ5#hTݒ HwI%~9T)bب
q#p=u\:IK'qE%Y`[6'=>HׇTKY<[EXXQAm)J:߱c
^kn2` (-WwL(fʆڄHX15g}e@jQoI<%oA\??JQ"X"K:+u~ɵy>fA%NqFt'^),!*(n^pQ\FG誹7lψ/<PS:qҮ"72DȞi0>6jʶSO uJZQVcL+;W?z@+mc-ف6D+ۖ: 2e3
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?129b610a-0f2b-4831-ea5f-9aa4c323cfa8>