What is the purpose of the MS_NOUSER flag serve and why is it set on
rootfs?
--
Thayne Harbaugh
Linux Networx
On Fri, 2005-01-07 at 19:32 +0200, Denis Vlasenko wrote:
> On Thursday 06 January 2005 17:08, Thayne Harbaugh wrote:
> > What is the purpose of the MS_NOUSER flag serve and why is it set on
> > rootfs?
>
> Was grep helpful?
No, it wasn't. There are (realling from memory) about six places that
MS_NOUSER appears in the entire tree.
One is in fs.h file where it is defined.
One is in in ramfs/inode.c (?) where MS_NOUSER is set on rootfs for
rootfs_get_sb()
One is in namespace.c in the graft_tree() function that prevents MS_BIND
Thrice in shmem.c - I have to admit I haven't read this very closely
One in libfs.c where there's a template for file systems that aren't
supposed to be mountable
One in Documentation/filesystems/porting where it describes that it can
be used in place of FS_NOMOUNT
There isn't a description as to what the intention is for MS_NOUSER and
why it should be applied to rootfs. I'm looking for some education as
to what it does so I can work out the details as to why it's used in
graft_tree(), rootfs_get_sb() and shmem.c.
It appears that Al Viro wrote some of that and I'm hoping that he can
find some time to reply (I'm sure he gets millions of emails about
little details and it's hard to cut through them). Maybe there's
someone else that understands that can give me an education or point me
in the right direction.
Thanks for your response.
--
Thayne Harbaugh
Linux Networx
On Fri, Jan 07, 2005 at 01:53:32PM -0700, Thayne Harbaugh wrote:
> On Fri, 2005-01-07 at 19:32 +0200, Denis Vlasenko wrote:
> > On Thursday 06 January 2005 17:08, Thayne Harbaugh wrote:
> > > What is the purpose of the MS_NOUSER flag serve and why is it set on
> > > rootfs?
Some random docs say
The <tt>FS_NOMOUNT</tt> flag says that this filesystem must never
be mounted from userland, but is used only kernel-internally.
This flag was introduced in 2.3.99-pre7 and disappeared in Linux 2.5.22.
This was used, for example, for pipefs, the implementation of Unix pipes
using a kernel-internal filesystem (see <tt>fs/pipe.c</tt>).
Even though the flag has disappeared, the concept remains,
and is now represented by the MS_NOUSER flag.
> There isn't a description as to what the intention is for MS_NOUSER and
> why it should be applied to rootfs. I'm looking for some education as
> to what it does so I can work out the details as to why it's used in
> graft_tree(), rootfs_get_sb() and shmem.c.
On Fri, 2005-01-07 at 22:45 +0100, Andries Brouwer wrote:
> On Fri, Jan 07, 2005 at 01:53:32PM -0700, Thayne Harbaugh wrote:
> > On Fri, 2005-01-07 at 19:32 +0200, Denis Vlasenko wrote:
> > > On Thursday 06 January 2005 17:08, Thayne Harbaugh wrote:
> > > > What is the purpose of the MS_NOUSER flag serve and why is it set on
> > > > rootfs?
>
> Some random docs say
Much thanks for the randomness.
> The <tt>FS_NOMOUNT</tt> flag says that this filesystem must never
> be mounted from userland, but is used only kernel-internally.
> This flag was introduced in 2.3.99-pre7 and disappeared in Linux 2.5.22.
> This was used, for example, for pipefs, the implementation of Unix pipes
> using a kernel-internal filesystem (see <tt>fs/pipe.c</tt>).
> Even though the flag has disappeared, the concept remains,
> and is now represented by the MS_NOUSER flag.
Okay, I can buy that there are filesystems, such as pipefs, that
shouldn't be mounted from userland. I'm wondering, however, why that
applies to rootfs. Is it a security reason (if it is, why - I'd like to
understand), is it a technical reason to simplify some VFS
requirement/limitation, or was it simply picked because it seemed to
make sense but it could be changed if something else made more sense?
Here's my application:
I have an early-userspace with early init programs and kernel modules.
Hotplug events load drivers and then the early init mounts the real
root. I want to take the modules from the early-userspace to the real
root by a mount bind of /lib/modules to /newroot/lib/modules. The mount
bind is the slickest way to do it rather than copying everything from /
to /newroot. That's where the MS_NOUSER is getting in the way.
I've removed MS_NOUSER from rootfs_get_sb() in my tree and things work
great. I'm just wondering if this might cause some real, unforeseen
problem or if it's something that might be changed in the main tree.
--
Thayne Harbaugh
Linux Networx