On Wed, Feb 20, 2019 at 10:20 AM Michael Olbrich <[email protected]> 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 < > [email protected]> > > 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 <[email protected]> > 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: jringle@dev-atl-bamb01:/srv/gpec-build/rootfs/platform-ec1c/packages/temp/data/usr/lib/systemd/network$ ll total 28 drwxr-xr-x 2 jringle domain^users 4096 Jan 1 00:00 ./ drwxr-xr-x 5 jringle domain^users 4096 Jan 1 00:00 ../ -rw-r----- 1 jringle domain^users 645 Jan 1 00:00 80-container-host0.network -rw-r----- 1 jringle domain^users 718 Jan 1 00:00 80-container-ve.network -rw-r----- 1 jringle domain^users 704 Jan 1 00:00 80-container-vz.network -rw-r--r-- 1 jringle domain^users 412 Jan 1 00:00 99-default.link -rw-r--r-- 1 jringle domain^users 70 Jan 1 00:00 eth0.network
_______________________________________________ ptxdist mailing list [email protected]
