On Tue, Jul 12, 2022 at 12:07 PM Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxx> wrote:
>
> Anything else is a bug. If you open a file, and then change the
> permissions of the file (or the ownership, or whatever) afterwards,
> the open file descriptor is still supposed to be readable or writable.
.. it works the other way too. If you have higher capabilities and
open a file, and then drop the capabilities after the open, the file
descriptor is still supposed to be available.
Again, doing some new permission check at IO time is wrong.
Of course, the sad part is that we have done that wrong thing many
times. Several /proc files have had fairly lax open-time permission
checks, and then they do stricter checks at IO time, and it's been a
serious security issue many many times.
Similarly, the traditionally horribly broken BSD model of "do SCSI
ioctl's using read/write calls" was a complete disaster in this area,
exactly because the permission checks were then done based on the IO
details (ie whatever command was written). And then that was
fundamental to the whole interface, because some commands require more
permissions than others, so you can't do the permission checks early.
This is largely why we then have that "file->f_cred" thing, so that
you can at least do things like "use the open-time credentials for
checking at IO time". Or just say "if open-time credentials are
different from IO time credentials, just abort".
That solves the SUID issue when the actor permissions ("credentials")
change, but it doesn't solve things like "somebody actually changed
the target file permissions themselves" issue. So those really have to
be tested at open time, and IO should not do "inode_permission()"
checks, because it's just fundamentally too late by then.
Of course, on eg stateless network filesystems, the IO-time permission
checks may be the only ones that the server side *can* do, and then
you end up with non-POSIX behavior and potential breakage.
The world is a messy place.
Linus
