On Wed, Feb 20, 2019 at 10:43 AM Michael Olbrich <m.olbrich@pengutronix.de> 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 <abbotti@mev.co.uk>
> > 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.04.
> > > > > > >>
> > > > > > >> 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
> > > > > > >> .
> > > > > > >> ├── [drwxr-x---]  attr-2.4.47
> > > > > > >> ├── [drwxr-x---]  avahi-0.7
> > > > > > >> ├── [drwxr-x---]  bash-4.3.30
> > > > > > >> ├── [drwxr-x---]  boost_1_67_0
> > > > > > >> ├── [drwxr-x---]  busybox-1.29.3
> > > > > > >> ├── [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 contain
> > 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 can 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 of
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