From: Hugo Valtier <hugo@valtier.fr>
To: mfasheh@suse.de, viro@zeniv.linux.org.uk,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: bug in may_dedupe_file allows to deduplicate files we aren't allowed to write to
Date: Sat, 4 May 2024 06:49:16 +0200 [thread overview]
Message-ID: <CAF+WW=oKQak6ktiOH75pHSDe7YEkYD-1ditgcsWB=z+aRKJogQ@mail.gmail.com> (raw)
For context I am making a file based deduplication tool.
I found that in this commit
5de4480ae7f8 ("vfs: allow dedupe of user owned read-only files")
it states:
> - the process could get write access
However the behavior added in allow_file_dedupe now may_dedupe_file is opposite:
> + if (!inode_permission(file_inode(file), MAY_WRITE))
> + return true
I've tested that I can create an other readonly file as root and have
my unprivileged user deduplicate it however if I then make the file
other writeable I cannot anymore*.
It doesn't make sense to me why giving write permissions on a file
should remove the permission to deduplicate*.
I'm not sure on how to fix this, flipping the condition would work but
that is a breaking change and idk if this is ok here.
Adding a check to also users who have write access to the file would
remove all the logic here since you would always be allowed to dedup
FDs you managed to get your hands on.
Any input on this welcome, thx
*without opening the file in write mode which I don't want to do
because it can prevent execution of files which is the exact thing is
5de4480ae7f8 were trying to address in the first place
next reply other threads:[~2024-05-04 4:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-04 4:49 Hugo Valtier [this message]
2024-05-04 9:43 ` bug in may_dedupe_file allows to deduplicate files we aren't allowed to write to Amir Goldstein
2024-05-04 20:50 ` Hugo Valtier
2024-05-05 6:57 ` Amir Goldstein
2024-05-07 22:14 ` Darrick J. Wong
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='CAF+WW=oKQak6ktiOH75pHSDe7YEkYD-1ditgcsWB=z+aRKJogQ@mail.gmail.com' \
--to=hugo@valtier.fr \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mfasheh@suse.de \
--cc=viro@zeniv.linux.org.uk \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).