From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-lj1-f179.google.com ([209.85.208.179]) by metis.ext.pengutronix.de with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1gwohY-0006Vg-Ko for ptxdist@pengutronix.de; Thu, 21 Feb 2019 14:47:49 +0100 Received: by mail-lj1-f179.google.com with SMTP id a17so7716611ljd.4 for ; Thu, 21 Feb 2019 05:47:48 -0800 (PST) MIME-Version: 1.0 References: <28b3d3f0-8281-64e5-ae67-2b43b49348b6@mev.co.uk> <20190220144202.pilz3kgql5k3hqz5@pengutronix.de> <20190220152020.b5bpa2k7ip65jyeq@pengutronix.de> <20190220154340.aviwfw35b5vxmcyv@pengutronix.de> In-Reply-To: <20190220154340.aviwfw35b5vxmcyv@pengutronix.de> From: Jon Ringle Date: Thu, 21 Feb 2019 08:47:36 -0500 Message-ID: Subject: Re: [ptxdist] strange permission behavior List-Id: PTXdist Development Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: ptxdist@pengutronix.de Content-Type: multipart/mixed; boundary="===============0570943867==" Errors-To: ptxdist-bounces@pengutronix.de Sender: "ptxdist" To: ptxdist@pengutronix.de --===============0570943867== Content-Type: multipart/alternative; boundary="0000000000002faea6058267b8bd" --0000000000002faea6058267b8bd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 20, 2019 at 10:43 AM Michael Olbrich wrote: > On Wed, Feb 20, 2019 at 10:29:45AM -0500, Jon Ringle wrote: > > On Wed, Feb 20, 2019 at 10:20 AM Michael Olbrich < > m.olbrich@pengutronix.de> > > wrote: > > > On Wed, Feb 20, 2019 at 10:10:01AM -0500, Jon Ringle wrote: > > > > On Wed, Feb 20, 2019 at 9:42 AM Michael Olbrich < > > > m.olbrich@pengutronix.de> > > > > wrote: > > > > > On Wed, Feb 20, 2019 at 09:09:18AM -0500, Jon Ringle wrote: > > > > > > On Wed, Feb 20, 2019 at 8:22 AM Ian Abbott > > > wrote: > > > > > > > > > > > > > On 20/02/2019 13:17, Ian Abbott wrote: > > > > > > > > On 20/02/2019 00:59, Jon Ringle wrote: > > > > > > > >> I've got a strange permission problem when I build on our > build > > > > > server > > > > > > > >> that was recently updated from Ubuntu-14.04 to Ubuntu-16.0= 4. > > > > > > > >> > > > > > > > >> On our Ubuntu-16.04 server, on most of the > platform/packages/ > > > > > > > >> subdirectories the packages are getting created with other > > > having no > > > > > > > >> permissions at all: > > > > > > > >> > > > > > > > >> rootfs/platform-ec1c/packages$ tree -d -L 1 -p > > > > > > > >> . > > > > > > > >> =E2=94=9C=E2=94=80=E2=94=80 [drwxr-x---] attr-2.4.47 > > > > > > > >> =E2=94=9C=E2=94=80=E2=94=80 [drwxr-x---] avahi-0.7 > > > > > > > >> =E2=94=9C=E2=94=80=E2=94=80 [drwxr-x---] bash-4.3.30 > > > > > > > >> =E2=94=9C=E2=94=80=E2=94=80 [drwxr-x---] boost_1_67_0 > > > > > > > >> =E2=94=9C=E2=94=80=E2=94=80 [drwxr-x---] busybox-1.29.3 > > > > > > > >> =E2=94=9C=E2=94=80=E2=94=80 [drwxr-x---] coreutils-8.29 > > > > > > > >> ... > > > > > > > >> > > > > > > > >> This results in all files contained within those > directories to > > > also > > > > > > > >> have no perms for other, and get installed on my target in > the > > > same > > > > > > > >> way. This in turn then causes permission problems to occur= . > > > > > > > >> > > > > > > > >> I'm at a loss as to what to look for to resolve this > problem. > > > > > > > >> > > > > > > > >> Suggestions? > > > > > > > > > > > > > > > > I think you are building with umask 0027, so files are > created > > > with > > > > > no > > > > > > > > permissions for 'other' users. This should not affect the > > > contents > > > > > of > > > > > > > > the platform-ec1c/packages/*.ipk files, or the contents of > the > > > > > > > > platform-ec1c/root/ directory, or the contents of the > > > > > > > > platform-ec1c/images/root.* images, which should all contai= n > > > files > > > > > with > > > > > > > > the correct permissions for the target. > > > > > > > > > > > > > > Correction: The platform-ec1c/root/ directory contents do not > have > > > the > > > > > > > correct ownership for the target, but the file mode bits > should be > > > > > correct. > > > > > > > > > > > > > > > > > > > > I also thought that perhaps it was a umask issue, but as you ca= n > see > > > > > below, > > > > > > umask is 0022, which should be ok. > > > > > > The permission problem that I am having on the target is that > > > > > > systemd-networkd.service won't start because it can't read the > > > > > > configuration files below. These files are installed in > systemd.make > > > via: > > > > > > > > > > > > ifdef PTXCONF_SYSTEMD_NETWORK > > > > > > @$(call install_tree, systemd, 0, 0, -, > > > /usr/lib/systemd/network) > > > > > > @$(call install_alternative_tree, systemd, 0, 0, > > > > > > /usr/lib/systemd/network) > > > > > > Another idea: This is in ptxdist or your BSP. What are the files > > > permissions there? > > > > > > > > My BSP doesn't have the directory, projectroot/usr/lib/systemd/network/ > > > > ptxdist projectroot is providing eth0.network, that has the correct > > permissions. > > jringle@dev-atl-bamb01 > :/usr/local/lib/ptxdist-2019.01.0_GP/projectroot/usr/lib/systemd/network$ > > ll > > total 12 > > drwxr-xr-x 2 root root 4096 Feb 12 05:18 ./ > > drwxr-xr-x 4 root root 4096 Feb 12 05:18 ../ > > -rw-r--r-- 1 root root 70 Feb 12 05:18 eth0.network > > > > The 80-container-*.network files that have the wrong permissions are > coming > > from the install_tree, not the install_alternative_tree, which is > provided > > by the systemd itself: > > Ok, lets start at the beginning. The directories in packages/ (and some o= f > the subdirectories are created with 'mkdir -p'. If you do that manually, > what kind of permissions do you get there? > > No need. The problem was introduced by a new version of bamboo that we had installed that changed the umask to 0027 for builds done via bamboo. This also caused the permissions to be incorrect on DEVPKGS that were used by further builds. Problem was fixed as described in the link below and be deleting and recreating the DEVPKGS. See https://community.atlassian.com/t5/Bamboo-questions/Permissions-trouble/qaq= -p/930046 -Jon --0000000000002faea6058267b8bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Feb 20, 2019 at = 10:43 AM Michael Olbrich <m.= olbrich@pengutronix.de> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Feb 20, 2019 at 10= :29:45AM -0500, Jon Ringle wrote:
> On Wed, Feb 20, 2019 at 10:20 AM Michael Olbrich <m.olbrich@pengutronix.de&g= t;
> wrote:
> > On Wed, Feb 20, 2019 at 10:10:01AM -0500, Jon Ringle wrote:
> > > On Wed, Feb 20, 2019 at 9:42 AM Michael Olbrich <
> > m.o= lbrich@pengutronix.de>
> > > wrote:
> > > > On Wed, Feb 20, 2019 at 09:09:18AM -0500, Jon Ringle wr= ote:
> > > > > On Wed, Feb 20, 2019 at 8:22 AM Ian Abbott <abbotti@mev.co.uk&g= t;
> > wrote:
> > > > >
> > > > > > On 20/02/2019 13:17, Ian Abbott wrote:
> > > > > > > On 20/02/2019 00:59, Jon Ringle wrote: > > > > > > >> I've got a strange permission pr= oblem when I build on our build
> > > > server
> > > > > > >> that was recently updated from Ubunt= u-14.04 to Ubuntu-16.04.
> > > > > > >>
> > > > > > >> On our Ubuntu-16.04 server, on most = of the platform/packages/
> > > > > > >> subdirectories the packages are gett= ing created with other
> > having no
> > > > > > >> permissions at all:
> > > > > > >>
> > > > > > >> rootfs/platform-ec1c/packages$ tree = -d -L 1 -p
> > > > > > >> .
> > > > > > >> =E2=94=9C=E2=94=80=E2=94=80 [drwxr-x= ---]=C2=A0 attr-2.4.47
> > > > > > >> =E2=94=9C=E2=94=80=E2=94=80 [drwxr-x= ---]=C2=A0 avahi-0.7
> > > > > > >> =E2=94=9C=E2=94=80=E2=94=80 [drwxr-x= ---]=C2=A0 bash-4.3.30
> > > > > > >> =E2=94=9C=E2=94=80=E2=94=80 [drwxr-x= ---]=C2=A0 boost_1_67_0
> > > > > > >> =E2=94=9C=E2=94=80=E2=94=80 [drwxr-x= ---]=C2=A0 busybox-1.29.3
> > > > > > >> =E2=94=9C=E2=94=80=E2=94=80 [drwxr-x= ---]=C2=A0 coreutils-8.29
> > > > > > >> ...
> > > > > > >>
> > > > > > >> This results in all files contained = within those directories to
> > also
> > > > > > >> have no perms for other, and get ins= talled on my target in the
> > same
> > > > > > >> way. This in turn then causes permis= sion problems to occur.
> > > > > > >>
> > > > > > >> I'm at a loss as to what to look= for to resolve this problem.
> > > > > > >>
> > > > > > >> Suggestions?
> > > > > > >
> > > > > > > I think you are building with umask 0027= , so files are created
> > with
> > > > no
> > > > > > > permissions for 'other' users.= =C2=A0 This should not affect the
> > contents
> > > > of
> > > > > > > the platform-ec1c/packages/*.ipk files, = or the contents of the
> > > > > > > platform-ec1c/root/ directory, or the co= ntents of the
> > > > > > > platform-ec1c/images/root.* images, whic= h should all contain
> > files
> > > > with
> > > > > > > the correct permissions for the target.<= br> > > > > > >
> > > > > > Correction: The platform-ec1c/root/ directory= contents do not have
> > the
> > > > > > correct ownership for the target, but the fil= e mode bits should be
> > > > correct.
> > > > > >
> > > > > >
> > > > > I also thought that perhaps it was a umask issue, = but as you can see
> > > > below,
> > > > > umask is 0022, which should be ok.
> > > > > The permission problem that I am having on the tar= get is that
> > > > > systemd-networkd.service won't start because i= t can't read the
> > > > > configuration files below. These files are install= ed in systemd.make
> > via:
> > > > >
> > > > > ifdef PTXCONF_SYSTEMD_NETWORK
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0@$(call install_t= ree, systemd, 0, 0, -,
> > /usr/lib/systemd/network)
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0@$(call install_a= lternative_tree, systemd, 0, 0,
> > > > > /usr/lib/systemd/network)
> >
> > Another idea: This is in ptxdist or your BSP. What are the files<= br> > > permissions there?
> >
> >
> My BSP doesn't have the directory, projectroot/usr/lib/systemd/net= work/
>
> ptxdist projectroot is providing eth0.network, that has the correct > permissions.
> jringle@dev-atl-bamb01:/usr/local/lib/ptxdist-2019.01.0_GP/projectroot= /usr/lib/systemd/network$
> ll
> total 12
> drwxr-xr-x 2 root root 4096 Feb 12 05:18 ./
> drwxr-xr-x 4 root root 4096 Feb 12 05:18 ../
> -rw-r--r-- 1 root root=C2=A0 =C2=A070 Feb 12 05:18 eth0.network
>
> The 80-container-*.network files that have the wrong permissions are c= oming
> from the install_tree, not the install_alternative_tree, which is prov= ided
> by the systemd itself:

Ok, lets start at the beginning. The directories in packages/ (and some of<= br> the subdirectories are created with 'mkdir -p'. If you do that manu= ally,
what kind of permissions do you get there?


No need. The problem was introduced by= a new version of bamboo that we had installed that changed the umask to 00= 27 for builds done via bamboo. This also caused the permissions to be incor= rect on DEVPKGS that were used by further builds. Problem was fixed as desc= ribed in the link below and be deleting and recreating the DEVPKGS.

-Jon

--0000000000002faea6058267b8bd-- --===============0570943867== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KcHR4ZGlzdCBt YWlsaW5nIGxpc3QKcHR4ZGlzdEBwZW5ndXRyb25peC5kZQ== --===============0570943867==--