From: Ian Kent <raven@themaw.net>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Paul Moore <paul@paul-moore.com>,
Miklos Szeredi <mszeredi@redhat.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-api@vger.kernel.org, linux-man@vger.kernel.org,
linux-security-module@vger.kernel.org,
Karel Zak <kzak@redhat.com>, David Howells <dhowells@redhat.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Al Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <christian@brauner.io>,
Amir Goldstein <amir73il@gmail.com>,
Matthew House <mattlloydhouse@gmail.com>,
Florian Weimer <fweimer@redhat.com>,
Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH v3 4/4] add listmount(2) syscall
Date: Fri, 13 Oct 2023 10:39:49 +0800 [thread overview]
Message-ID: <c45fc3e5-05ca-14ab-0536-4f670973b927@themaw.net> (raw)
In-Reply-To: <7fe3c01f-c225-394c-fac5-cabfc70f3606@themaw.net>
On 6/10/23 08:27, Ian Kent wrote:
> On 5/10/23 23:47, Miklos Szeredi wrote:
>> On Thu, 5 Oct 2023 at 06:23, Ian Kent <raven@themaw.net> wrote:
>>
>>> The proc interfaces essentially use <mount namespace>->list to provide
>>>
>>> the mounts that can be seen so it's filtered by mount namespace of the
>>>
>>> task that's doing the open().
>>>
>>>
>>> See fs/namespace.c:mnt_list_next() and just below the m_start(),
>>> m_next(),
>> /proc/$PID/mountinfo will list the mount namespace of $PID. Whether
>> current task has permission to do so is decided at open time.
>>
>> listmount() will list the children of the given mount ID. The mount
>> ID is looked up in the task's mount namespace, so this cannot be used
>> to list mounts of other namespaces. It's a more limited interface.
>
> Yep. But isn't the ability to see these based on task privilege?
>
>
> Is the proc style restriction actually what we need here (or some
> variation
>
> of that implementation)?
>
>
> An privileged task typically has the init namespace as its mount
> namespace
>
> and mounts should propagate from there so it should be able to see all
> mounts.
>
>
> If the file handle has been opened in a task that is using some other
> mount
>
> namespace then presumably that's what the program author wants the
> task to see.
>
> So I'm not sure I see a problem obeying the namespace of a given task.
I've had a look through the code we had in the old fsinfo() proposal
because I think we need to consider the use cases that are needed.
IIRC initially we had a flag FSINFO_ATTR_MOUNT_CHILDREN that essentially
enumerated the children of the given mount in much the same way as is
done now in this system call.
But because we needed to enumerate mounts in the same way as the proc file
system mount tables a flag FSINFO_ATTR_MOUNT_ALL was added that essentially
used the mount namespace mounts list in a similar way to the proc file
system so that a list of mounts for a mount namespace could be retrieved.
This later use case is what is used by processes that monitor mounts and
is what's needed more so than enumerating the children as we do now.
I'm still looking at the mount id lookup.
Ian
>
>
> Ian
>
>>
>> I sort of understand the reasoning behind calling into a security hook
>> on entry to statmount() and listmount(). And BTW I also think that if
>> statmount() and listmount() is limited in this way, then the same
>> limitation should be applied to the proc interfaces. But that needs
>> to be done real carefully because it might cause regressions. OTOH if
>> it's only done on the new interfaces, then what is the point, since
>> the old interfaces will be available indefinitely?
>>
>> Also I cannot see the point in hiding some mount ID's from the list.
>> It seems to me that the list is just an array of numbers that in
>> itself doesn't carry any information.
>>
>> Thanks,
>> Miklos
next prev parent reply other threads:[~2023-10-13 2:40 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-28 13:01 [PATCH v3 0/4] querying mount attributes Miklos Szeredi
2023-09-28 13:01 ` [PATCH v3 1/4] add unique mount ID Miklos Szeredi
2023-10-05 15:52 ` Miklos Szeredi
2023-10-06 11:44 ` Amir Goldstein
2023-10-06 12:48 ` Miklos Szeredi
2023-09-28 13:01 ` [PATCH v3 2/4] namespace: extract show_path() helper Miklos Szeredi
2023-09-28 13:01 ` [PATCH v3 3/4] add statmount(2) syscall Miklos Szeredi
2023-09-29 0:42 ` Ian Kent
2023-09-29 9:10 ` Miklos Szeredi
2023-09-30 1:16 ` Ian Kent
2023-10-04 19:26 ` Paul Moore
2023-09-28 13:01 ` [PATCH v3 4/4] add listmount(2) syscall Miklos Szeredi
2023-10-04 19:37 ` Paul Moore
2023-10-05 4:01 ` Miklos Szeredi
2023-10-05 4:23 ` Ian Kent
2023-10-05 15:47 ` Miklos Szeredi
2023-10-06 0:27 ` Ian Kent
2023-10-13 2:39 ` Ian Kent [this message]
2023-10-24 13:57 ` Miklos Szeredi
2023-10-06 2:56 ` Paul Moore
2023-10-06 8:53 ` Miklos Szeredi
2023-10-06 23:07 ` Paul Moore
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=c45fc3e5-05ca-14ab-0536-4f670973b927@themaw.net \
--to=raven@themaw.net \
--cc=amir73il@gmail.com \
--cc=arnd@arndb.de \
--cc=christian@brauner.io \
--cc=dhowells@redhat.com \
--cc=fweimer@redhat.com \
--cc=kzak@redhat.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mattlloydhouse@gmail.com \
--cc=miklos@szeredi.hu \
--cc=mszeredi@redhat.com \
--cc=paul@paul-moore.com \
--cc=torvalds@linux-foundation.org \
--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).