From: "Yann E. MORIN" <yann.morin.1998@free.fr>
To: Arnout Vandecappelle <arnout@rnout.be>
Cc: buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH 05/13] support/scripts: fix and restrict conditions to accept merged dirs
Date: Sat, 17 May 2025 17:02:30 +0200 [thread overview]
Message-ID: <aCilBmBGrMpn-QNU@landeda> (raw)
In-Reply-To: <3d14a905-269b-496a-9891-f63d05bd60a5@rnout.be>
Arnout, All,
On 2025-05-17 12:13 +0200, Arnout Vandecappelle spake thusly:
> On 17/05/2025 09:59, Yann E. MORIN wrote:
> > On 2025-05-14 18:58 +0200, Yann E. MORIN spake thusly:
> > > Currently, we accept that the merged usr is bqckward, i.e. that the
> > > /usr/bin, /usr/sbin, and /usr/lib entries be symlinks to, resp., /bin,
> > > /sbin, and /lib. We also allow either entries to be symlinks to other
> > > parts of the root. Both are accepted despite the comment at the top of
> > > the script explaining what should be accepted.
> > >
> > > However, a properly merged usr is the other way around: /bin, /sbin, and
> > > /lib are the symlinks to resp. /usr/bin, /usr/sbin, and /usr/lib, and
> > > the latters are actual directories.
> > [--SNIP--]
> > > @@ -32,12 +29,21 @@ test_merged() {
> > > local dir2="${3}"
> > > local inode1 inode2
> > > + # OK if missing first entry and second entry is an actual directory
> > > + test -e "${root}${dir1}" || { test -d "${root}${dir2}" && return; }
> > > +
> > > inode1="$(stat -c '%i' "${root}${dir1}/." 2>/dev/null)"
> > > inode2="$(stat -c '%i' "${root}${dir2}/." 2>/dev/null)"
> > > - test -z "${inode1}" || \
> > > - test "${inode1}" = "${inode2}" || \
> > > - printf '%s\n' "${dir1}"
> > > + # OK if first entry is a symlink, second entry is a directoy, and
> > > + # both have the same inode (once dereferenced)
> > > + test -L "${root}${dir1}" \
> > > + && test -d "${root}${dir2}" \
> > > + && test "${inode1}" = "${inode2}" \
> > > + && return
> > > +
> > > + # Otherwise, this directory is not merged
> > > + printf '%s\n' "${dir1}"
> >
> > This new test is still quite complex, and is in fact still wrong in
> > weird cases. For example, with BASE a custom skeleton or rootfs overlay,
> > if BASE/sbin and BASE/usr/sbin ar absolute symlinks to /usr/sbin, the
> > test above will accept BASE as being properly merged, while it is in
> > fact broken.
> >
> > I'm preparing a v2 which greatly simplifies the test, and makes it cover
> > more (all, hopefully) cases.
>
> I guess the test should simply be:
>
> test -L "${root}${dir1}" \
> && test -d "${root}${dir2}" \
> && test "$(readlink "${root}${dir1}")" = "${dir2}" \
This test for the target of the symlink is wrong: if dir1 is bin, and
points to /usr/bin, then this is wrong: we really want relative
symlinks.
> && return
>
> (which is not actually simpler... except that you can remove all the stat stuff)
I'm going with an even simpler, more strict solution, that simply
implements word-for-word our requirements. Indeed, I just drop all the
stat stuff that could get things wrong.
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
next prev parent reply other threads:[~2025-05-17 15:02 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-14 16:58 [Buildroot] [PATCH 00/13] system: add support for merged-bin (branch yem/merged-bin) Yann E. MORIN
2025-05-14 16:58 ` [Buildroot] [PATCH 01/13] system: reword merged-usr prompt Yann E. MORIN
2025-05-17 10:07 ` Arnout Vandecappelle via buildroot
2025-05-14 16:58 ` [Buildroot] [PATCH 02/13] system: drop superfluous negative condition for default PATH Yann E. MORIN
2025-05-17 10:07 ` Arnout Vandecappelle via buildroot
2025-05-14 16:58 ` [Buildroot] [PATCH 03/13] package/systemd: select merged-usr from package, not init Yann E. MORIN
2025-05-17 10:07 ` Arnout Vandecappelle via buildroot
2025-05-14 16:58 ` [Buildroot] [PATCH 04/13] support/scripts: comonalise checking merged status Yann E. MORIN
2025-05-17 10:08 ` Arnout Vandecappelle via buildroot
2025-05-14 16:58 ` [Buildroot] [PATCH 05/13] support/scripts: fix and restrict conditions to accept merged dirs Yann E. MORIN
2025-05-17 7:59 ` Yann E. MORIN
2025-05-17 9:12 ` Arnout Vandecappelle via buildroot
2025-05-17 10:13 ` Arnout Vandecappelle via buildroot
2025-05-17 15:02 ` Yann E. MORIN [this message]
2025-05-14 16:58 ` [Buildroot] [PATCH 06/13] support/scripts: rename check-merged-usr.sh Yann E. MORIN
2025-05-17 10:35 ` Arnout Vandecappelle via buildroot
2025-05-14 16:58 ` [Buildroot] [PATCH 07/13] support/scripts; teach check-merged what to check Yann E. MORIN
2025-05-17 10:24 ` Arnout Vandecappelle via buildroot
2025-05-17 15:07 ` Yann E. MORIN
2025-05-14 16:58 ` [Buildroot] [PATCH 08/13] system: add support for merged /usr/sbin (aka merged-bin) Yann E. MORIN
2025-05-17 10:38 ` Arnout Vandecappelle via buildroot
2025-05-17 16:52 ` Edgar Bonet via buildroot
2025-05-17 20:10 ` Yann E. MORIN
2025-05-14 16:58 ` [Buildroot] [PATCH 09/13] package/systemd: require merged-bin Yann E. MORIN
2025-05-17 10:38 ` Arnout Vandecappelle via buildroot
2025-05-14 16:58 ` [Buildroot] [PATCH 10/13] package/coreutils: no need for chroot workaround with merged-bin Yann E. MORIN
2025-05-14 16:58 ` [Buildroot] [PATCH 11/13] package/kmod: adjust paths for merged-bin Yann E. MORIN
2025-05-14 16:58 ` [Buildroot] [PATCH 12/13] package/util-linux: " Yann E. MORIN
2025-05-14 16:58 ` [Buildroot] [PATCH 13/13] toolchain/external: support merged-bin Yann E. MORIN
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=aCilBmBGrMpn-QNU@landeda \
--to=yann.morin.1998@free.fr \
--cc=arnout@rnout.be \
--cc=buildroot@buildroot.org \
/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