Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 16 Jun 2017 10:52:57 -0500
From:      Karl Denninger <karl@denninger.net>
To:        freebsd-stable@freebsd.org
Subject:   Re: Interesting permissions difference on NanoBSD build
Message-ID:  <51250937-eb64-bd50-b63c-0725439bb20b@denninger.net>
In-Reply-To: <129b610a-0f2b-4831-ea5f-9aa4c323cfa8@denninger.net>
References:  <a6e9db4f-235e-bd40-e361-a8af84a68186@denninger.net> <1387791f-fe22-08d7-2048-26bd95eab451@madpilot.net> <0561597d-4b24-f68e-33a8-d0902e7696da@denninger.net> <129b610a-0f2b-4831-ea5f-9aa4c323cfa8@denninger.net>

next in thread | previous in thread | raw e-mail | index | archive | help

[-- Attachment #1 --]


On 6/16/2017 09:55, Karl Denninger wrote:
> 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
I found the problem -- the customize file function that I was using was
picking up the directory tree permissions in the source and applying it
across the board; the error was in there.

Disregard; the script is ok; this is a potential mine field in its use,
but it's one that falls under "user error" in terms of category :-)

-- 
Karl Denninger
karl@denninger.net <mailto:karl@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/

[-- Attachment #2 --]
0	*H
010
	`He0	*H
\0X0@=0
	*H
010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems LLC CA1"0 	*H
	Cuda Systems LLC CA0
161218194535Z
211217194535Z0W10	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<m4BeSet|
l2m 6iO{wv
+aHXˈ5=~é*C!?uJr3tb'3`Oe)üLxt&3N526llU
.|Cp[l?007++0)0'+0http://cudasystems.net:88880	U00	`HB0U0,	`HB
OpenSSL Generated Certificate0U/Zi
0GhG0U#0$q}ݽʒm50U0karl@denninger.net0
	*H
b%X%gwq	
ɁэrK[DMJ35W6
sz8d|qB2Cyw2PbV}
â[!W{HD7oD.TZ'w6~g( -,]R8P{*[f<1=7jGj9铚~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|Za1򹿈nZ5TuPvW|#G+	DZpI7S'n0 haGa@vZ	e|]Cu+))vRyY100010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems LLC CA1"0 	*H
	Cuda Systems LLC CA=0
	`HeM0	*H
	1	*H
0	*H
	1
170616155257Z0O	*H
	1B@	+A`*YĿBw|U)Jl~zqTyp̵1f0l	*H
	1_0]0	`He*0	`He0
*H
0*H
0
*H
@0+0
*H
(0	+710010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems LLC CA1"0 	*H
	Cuda Systems LLC CA=0*H
	1010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems LLC CA1"0 	*H
	Cuda Systems LLC CA=0
	*H
S~3
vV6ł'5J@Xks;·LOCpl$nwk&pQB(4҇<F6i%-
'-D41!#49.qlv3-v4zt0Ruhό#Ù'G<d]@>1L!b]lƫ-<7s>j֜)lrcO2PsȪhWBZ=mP9"YIl!gZ_Tr~bJOr,O-YnFKXCY2X6H[\.1<c.U/1ʯIOq'8^rŐ>ѯH["]N=^dțg|]Is1;:q3T٭GezV6N oWtee@uc|h1=,@a{\jTN"c|;3@T:]` (i760(=Ep .-`zlroZ1NI,iݦ"0i[(g\wp.^+c	,[դ
mÃLԅUNOFKtjt

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51250937-eb64-bd50-b63c-0725439bb20b>