linux-kernel - Re: request for patches: showing mount options

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 31 Jul 2007 10:19:57 -0400
From:	Chuck Lever <chuck.lever@...cle.com>
To:	Miklos Szeredi <miklos@...redi.hu>
CC:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	kzak@...hat.com, sfrench@...ba.org, trond.myklebust@....uio.no,
	mark.fasheh@...cle.com, kurt.hackel@...cle.com
Subject: Re: request for patches: showing mount options

Miklos Szeredi wrote:
>> After a successful mount, the NFS mount command tucks some options into 
>> /etc/mtab that reflect which mountd was used for the mount, and what 
>> protocol version and port was used for the mount request.  Those options 
>> are not passed to the kernel, and do not appear in /proc/mounts today. 
>> See nfs(5)'s discussion of the mountport, mounthost, mountprog, and 
>> mountvers options.
>>
>> However, the trend for NFS is to push mount option parsing into the 
>> kernel.  Thus all options will be passed to the kernel, and at that 
>> point it should be able to reflect the mount* options in /proc/mounts. 
>> But it doesn't do that quite yet.
> 
> Trond, do you have a roadmap for this?

Well I'm actually doing the coding, and Trond is playing more of an 
architectural role.

We have a first implementation of in-kernel mount option parsing in 
2.6.23-rc now.  I'm currently working on the user-space piece of this. 
(And actually, now is a great time to review the new kernel part, while 
it is still quite young.)

However, the NFS mount user-space pieces have undergone radical change 
recently.  The mount.nfs helper was split from the mount command just 
last year, and is only now starting to go into distributions.  This is 
very old code that has been hacked on for over a decade, so it is taking 
a little while to rediscover its history and modernize it before we move 
forward.

I expect that both the kernel part and the user-space part will evolve 
together over the next few months as we clarify the full set of 
requirements.  The requirements for this effort now include:

+ making new mount options simple to implement;

+ removing ABI dependencies between mount.nfs and the kernel NFS client;

+ an eventual merge of the nfs and nfs4 file system types;

+ improved error handling and reporting during the mount process;

+ support for NFS over IPv6.

I think there is also some talk about fully supporting SELinux as well, 
but I haven't been following that closely.

The removal of /etc/mtab in favor of /proc/mounts is a new requirement, 
and is not as trivial as you might hope.  Internally the NFS client 
represents the mount options as a binary data structure, and it contains 
only the information that has traditionally been passed into the kernel 
by the current mount command.  The user-space-only options are not 
passed to the kernel nor stored in the data structure.

Adding facilities to store information about every possible mount 
option, including the user-space-only ones, will take a bit of time, but 
is possible, if not straightforward.  We just have to understand all the 
dependencies.

View attachment "chuck.lever.vcf" of type "text/x-vcard" (291 bytes)