mailarchive of the ptxdist mailing list
 help / color / mirror / Atom feed
From: Michael Olbrich <m.olbrich@pengutronix.de>
To: ptxdist@pengutronix.de
Subject: Re: [ptxdist] Root filesystem creation regression
Date: Mon, 22 Jun 2020 10:47:46 +0200	[thread overview]
Message-ID: <20200622084746.GA23174@pengutronix.de> (raw)
In-Reply-To: <202006220955.51237.jbe@pengutronix.de>

On Mon, Jun 22, 2020 at 09:55:51AM +0200, Juergen Borleis wrote:
> since commit 9c0ec1da583f32706372d2a6cefa9a05f77ee8d2
>   "ptxd_lib_check_dir_permissions: also check parents for directories"
> 
> the "install_tree" macro may create directories which makes this test fail and 
> I'm unable to create root filesystems anymore.
> 
> The problem pops up if "install_tree" tries to install a file to a directory 
> which has different permissions than the usual ones (0775, root:root).
> 
> For example: "systemd" sets up the "/usr/share/dbus-1/system-services" with 
> permissions 0755. If my own package tries to add another file to this directory 
> the corresponding "install" tool in the install stage creates the whole path 
> with standard 0755 permissions - because the "filesystem" in the package 
> directory (e.g. platform-<name>/packages/<package>) is always empty. In a 
> regular root filesystem it works, because the directory structure already 
> exists (with the intended permissions), and the "install" tool has to copy the 
> file only.
> 
> Using "install_tree" in my package in this case creates a conflict for 
> the "system-services" directory (0755 versus 0775). I guess it will fail at 
> more locations than only "install_tree", if someone adds more and more accurate 
> permissions due to security reasons.

So the error you got was that systemd tries to create system-services with
0755 and your package tries to create it with 0775, right?
This is no longer supported. All packages must create the same directories
with the same permissions.

The problem is that, in general, when two ipkgs contain the same directory
with different permissions then the result was non-deterministic. Either
permission could end up in the rootfs. For rootfs images we 'fixed' this by
applying all permissions again. However, that is only deterministic if only
on package provides explicit permissions for the directory. And that was
not checked.
And even that case is not without problems: This only works, wenn ptxdist
created rootfs images. It does not work when ipkgs are used in any other
way. And if the package that provides the permissions is disabled, then the
permissions change for the remaining system. That is not something that
should happen.

So if a directory has non standard permissions, then all packages that
install into this directory must created the directory first, with the
correct permissions.
FYI, this was broken in the last ptxdist release, but it should be fixed in
master.

'install_tree' is a bit of a special case here. The problem ist, that it
cannot know, which directories are implicit. So it will always create all
subdirectories (except the root directory of the tree). So you need to fix
the permission in the install stage.

Michael

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
To unsubscribe, send a mail with subject "unsubscribe" to ptxdist-request@pengutronix.de

  reply	other threads:[~2020-06-22  8:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-22  7:55 Juergen Borleis
2020-06-22  8:47 ` Michael Olbrich [this message]
2020-06-22  9:14   ` Juergen Borleis
2020-06-22 12:37     ` Michael Olbrich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200622084746.GA23174@pengutronix.de \
    --to=m.olbrich@pengutronix.de \
    --cc=ptxdist@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox