Re: [PATCH] file: always lock position

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 24 Jul 2023 at 09:19, Christian Brauner <brauner@xxxxxxxxxx> wrote:
>
> SCM_RIGHTS which have existed since 2.1 or sm allow you to do the same
> thing just cooperatively. If you receive a bunch of fds from another
> task including sockets and so on they refer to the same struct file.

Yes, but it has special synchronization rules, eg big comment in
commit cbcf01128d0a ("af_unix: fix garbage collect vs MSG_PEEK").

There are magic rules with "total_refs == inflight_refs", and that
total_refs thing is very much the file count, ie

                total_refs = file_count(u->sk.sk_socket->file);

where we had some nasty bugs with files coming back to life.

> In recent kernels we also have the seccomp notifier addfd ioctl which
> let's you add a file descriptor into another process which can also be
> used to create shared struct files.

Note that shared files aren't a problem per se. The most obvious case
is just 'dup()'. It's been around forever.

What's a problem is a file that *isn't* shared magically becoming
shared without the process being aware of it.

Both SCM file passing and the seccomp addfd cases are synchronous wrt
the source file descriptor and don't add any references from
"outside".

             Linus



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux