Re: [RFC] shmgetfd idea

[Kay Sievers <kay@vrfy.org>]

On Wed, Jan 29, 2014 at 12:19 AM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 01/28/2014 03:14 PM, Kay Sievers wrote:
>>
>> What would be the interface for additional functionality like
>> sealing/unsealing that thing, that no operation can destruct its
>> content as long as there is more than a single owner? That would be a
>> new syscall or fcntl() with specific shmemfd options?
>>
>> We also need to solve the problem that the inode does not show up in
>> /proc/$PID/fd/, so that nothing can create a new file for it which we
>> don't catch with the "single owner" logic. Or we could determine the
>> "single owner" state from the inode itself?
>>
>
> If the "single owner" is determined by the file structure (e.g. via a
> fcntl as opposed to a ioctl), then presumably we would simply deny an
> attempt to open the inode and create a new file structure for it.
>
> On Linux, /proc/$PID/fd is an open as opposed to a dup (as much as I
> personally don't like those semantics, they are well set in stone at
> this point) so it satisfies your requirements.

If that all could be made working, for the kdbus case we would be fine
with requiring *any* tmpfs mount, create a new memfd from there with
O_TMPFILE, and use new fcntl() definitios to protect/seal/unseal and
identify that fd.

For the more restricted cases like Android that tmpfs mount could get
a mount option to not allow the creation of any non-unlinked file, I
guess.

Kay

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>