From: Luis Henriques <[email protected]>
To: Al Viro <[email protected]>
Cc: Christian Brauner <[email protected]>,
Jens Axboe <[email protected]>,
Pavel Begunkov <[email protected]>,
[email protected], [email protected],
[email protected]
Subject: Re: [RFC PATCH] fs: add AT_EMPTY_PATH support to unlinkat()
Date: Mon, 09 Oct 2023 16:14:27 +0100 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <20231009020623.GB800259@ZenIV> (Al Viro's message of "Mon, 9 Oct 2023 03:06:23 +0100")
Al Viro <[email protected]> writes:
> On Fri, Sep 29, 2023 at 03:04:56PM +0100, Luis Henriques wrote:
>
>> -int do_unlinkat(int dfd, struct filename *name)
>> +int do_unlinkat(int dfd, struct filename *name, int flags)
>> {
>> int error;
>> - struct dentry *dentry;
>> + struct dentry *dentry, *parent;
>> struct path path;
>> struct qstr last;
>> int type;
>> struct inode *inode = NULL;
>> struct inode *delegated_inode = NULL;
>> unsigned int lookup_flags = 0;
>> -retry:
>> - error = filename_parentat(dfd, name, lookup_flags, &path, &last, &type);
>> - if (error)
>> - goto exit1;
>> + bool empty_path = (flags & AT_EMPTY_PATH);
>>
>> - error = -EISDIR;
>> - if (type != LAST_NORM)
>> - goto exit2;
>> +retry:
>> + if (empty_path) {
>> + error = filename_lookup(dfd, name, 0, &path, NULL);
>> + if (error)
>> + goto exit1;
>> + parent = path.dentry->d_parent;
>> + dentry = path.dentry;
>> + } else {
>> + error = filename_parentat(dfd, name, lookup_flags, &path, &last, &type);
>> + if (error)
>> + goto exit1;
>> + error = -EISDIR;
>> + if (type != LAST_NORM)
>> + goto exit2;
>> + parent = path.dentry;
>> + }
>>
>> error = mnt_want_write(path.mnt);
>> if (error)
>> goto exit2;
>> retry_deleg:
>> - inode_lock_nested(path.dentry->d_inode, I_MUTEX_PARENT);
>> - dentry = lookup_one_qstr_excl(&last, path.dentry, lookup_flags);
>> + inode_lock_nested(parent->d_inode, I_MUTEX_PARENT);
>> + if (!empty_path)
>> + dentry = lookup_one_qstr_excl(&last, parent, lookup_flags);
>
> For starters, your 'parent' might have been freed under you, just as you'd
> been trying to lock its inode. Or it could have become negative just as you'd
> been fetching its ->d_inode, while we are at it.
>
> Races aside, you are changing permissions required for removing files. For
> unlink() you need to be able to get to the parent directory; if it's e.g.
> outside of your namespace, you can't do anything to it. If file had been
> opened there by somebody who could reach it and passed to you (via SCM_RIGHTS,
> for example) you currently can't remove the sucker. With this change that
> is no longer true.
>
> The same goes for the situation when file is bound into your namespace (or
> chroot jail, for that matter). path.dentry might very well be equal to
> root of path.mnt; path.dentry->d_parent might be in part of tree that is
> no longer visible *anywhere*. rmdir() should not be able to do anything
> with it...
>
> IMO it's fundamentally broken; not just implementation, but the concept
> itself.
>
> NAKed-by: Al Viro <[email protected]>
Thank you for your review, which made me glad I sent out the patch early
as an RFC. I (think I) understand the issues you pointed out and,
although some of them could be fixed (the races), I guess there's no point
pursuing this any further, since you consider the concept itself to be
broken. Again, thank you for your time.
Cheers,
--
Luís
next prev parent reply other threads:[~2023-10-09 15:15 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-29 14:04 [RFC PATCH] fs: add AT_EMPTY_PATH support to unlinkat() Luis Henriques
2023-10-09 2:06 ` Al Viro
2023-10-09 15:14 ` Luis Henriques [this message]
2023-10-10 5:47 ` Clay Harris
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 \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/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