Re: [PATCH] Add new open(2) flag - O_EMPTY_PATH

From: Andrew Walker
Date: Wed Apr 26 2023 - 09:10:37 EST


On Wed, Apr 19, 2023 at 4:29 PM David Laight <David.Laight@xxxxxxxxxx> wrote:
> ISTM that reopening a file READ_WRITE shouldn't be unconditionally allowed.
> Checking the inode permissions of the file isn't enough to ensure
> that the process is allowed to open it.
> The 'x' (search) permissions on all the parent directories needs to
> be checked (going back as far as some directory the process has open).
>
> If a full pathname is generated this check is done.
> But the proposed O_EMTPY_PATH won't be doing it.
>
> This all matters if a system is using restricted directory
> permissions to block a process from opening files in some
> part of the filesystem, but is also being passed an open
> fd (for reading) in that part of the filesystem.
> I'm sure there are systems that will be doing this.
>
> David
>

So to be safe, hypothetically, the caller should be required to have
CAP_DAC_READ_SEARCH like with open_by_handle_at(2)?

Andrew