From: "Seebs" <seebs@seebs.net>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 6/9] pseudo: Add may unlink patch
Date: Mon, 12 Oct 2020 14:20:45 -0500 [thread overview]
Message-ID: <20201012142045.66f28cb8@seebsdell> (raw)
In-Reply-To: <20201007101449.3132127-6-richard.purdie@linuxfoundation.org>
On Wed, 7 Oct 2020 11:14:46 +0100
Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> +Some operations may call unlink() on an open fd, then call
> fchown/fchmod/fstat +on that fd. This would currently readd its entry
> to the database, which +is necessary to preserve its permissions
> information however since that +file will be lost when it is closed,
> we don't want the DB entry to persist. +Marking it as may_unlink
> means the code will know its likely been deleted +and ignore the
> entry later, giving improved behaviour that simple path +mismatch
> warnings. We can use an nlink of zero to detect this.
Eww.
This seems like it could create a bug. I would argue that calling
fchown/fchmod on an unlinked thing is almost always a sign that
something's wrong. I guess fstat is reasonable, but in the fstat case,
it seems to me that there's a risk that the newly created entry won't
match the properties the file last had. If you have a file in the
database owned by root, and then you unlink it, and then call fstat on
it, the fstat entry would show it being owned by the user, and if we
then create a DB entry with the user's ownership, that's actually sort
of wrong.
But I can't immediately see a way to create a new link from just a
file descriptor, so it should be short-lived, anyway.
-s
next prev parent reply other threads:[~2020-10-12 19:20 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-07 10:14 [PATCH 1/9] pseudo: Ignore mismatched inodes from the db Richard Purdie
2020-10-07 10:14 ` [PATCH 2/9] pseudo: Add support for ignoring paths from the pseudo DB Richard Purdie
2020-10-12 19:31 ` Seebs
2020-10-12 20:48 ` Richard Purdie
2020-10-07 10:14 ` [PATCH 3/9] pseudo: Abort on mismatch patch Richard Purdie
2020-10-07 10:14 ` [PATCH 4/9] psuedo: Add tracking of linked files for fds Richard Purdie
2020-10-12 19:27 ` Seebs
2020-10-07 10:14 ` [PATCH 5/9] pseudo: Fix xattr segfault Richard Purdie
2020-10-12 19:22 ` Seebs
2020-10-07 10:14 ` [PATCH 6/9] pseudo: Add may unlink patch Richard Purdie
2020-10-12 19:20 ` Seebs [this message]
2020-10-12 20:33 ` Richard Purdie
2020-10-07 10:14 ` [PATCH 7/9] pseudo: Add pathfix patch Richard Purdie
2020-10-07 10:14 ` [PATCH 8/9] base/bitbake.conf: Enable pseudo path filtering Richard Purdie
2020-10-07 10:14 ` [PATCH 9/9] wic: Handle new PSEUDO_IGNORE_PATHS variable Richard Purdie
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=20201012142045.66f28cb8@seebsdell \
--to=seebs@seebs.net \
--cc=openembedded-core@lists.openembedded.org \
--cc=richard.purdie@linuxfoundation.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