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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <46AFA6AB.8080208@oracle.com>
Date:	Tue, 31 Jul 2007 17:16:27 -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.
> 
> OK, what your estimage for this then?

I don't have an estimate.  This is all very slippery because once I get 
into a part of the code, we discover a lot of issues that we didn't 
expect.  The NFS mount stuff is largely historical; we've all forgotten 
(or never really knew) how it works.

> It would be nice to have all this stuff in 2.6.24, which doesn't leave
> a lot of time.

Yes, that would be nice, but there's a lot of stuff that needs to get 
done before this.  NFS IPv6, for example, is a higher priority than 
refactoring to remove /etc/mtab -- the US government has a new 
requirement in 2008 for IPv6 support in any software that it purchases, 
and NFS may be a stumbling block for distributors if it doesn't have it.

So I'd say "no way" for 2.6.24, but it's really Trond's call to make.

> But if it's just those four options you mentioned, it should be
> managable.  I do not think there needs to be some generic code to
> hande userspace-only options, it would be perfectly fine just to
> parse, store and show them like all the other options.

Like you, I don't expect it will be difficult to implement, but I have 
too many balls in the air to make any promises at the moment.  Plus, we 
can't really predict when distributors will feel the in-kernel mount 
parsing stuff will be ready for their users.

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