linux-kernel - Re: Adding subroot information to /proc/mounts, or obtaining that through other means

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: <4679B1F6.6080408@oracle.com>
Date:	Wed, 20 Jun 2007 19:02:14 -0400
From:	Chuck Lever <chuck.lever@...cle.com>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-fsdevel@...r.kernel.org, util-linux-ng@...r.kernel.org
Subject: Re: Adding subroot information to /proc/mounts, or obtaining that
 through other means

H. Peter Anvin wrote:
> Chuck Lever wrote:
>> The advantage is that it doesn't have strong user space dependencies on
>> its format like /proc/mounts does.
>>
>> If you have NFS mount points, you will see that it includes a great deal
>> of additional information about each mount.
> 
> OK, I see now:
> device raidtest:/export mounted on /net/raidtest/export with fstype nfs
> statvers=1.0
>         opts:
> rw,vers=3,rsize=131072,wsize=131072,acregmin=3,acregmax=60,acdirmin=30,acdirmax=60,hard,proto=tcp,timeo=600,retrans=2,sec=sys
>         age:    5
>         caps:   caps=0x9,wtmult=4096,dtsize=4096,bsize=0,namelen=255
>         sec:    flavor=1,pseudoflavor=1
>         events: 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>         bytes:  0 0 0 0 0 0 0 0
>         RPC iostats version: 1.0  p/v: 100003/3 (nfs)
>         xprt:   tcp 686 0 2 0 5 8 8 0 8 0
>         per-op statistics
>                 NULL: 0 0 0 0 0 0 0 0
>              GETATTR: 2 2 0 264 224 1 0 1
>              SETATTR: 0 0 0 0 0 0 0 0
>               LOOKUP: 0 0 0 0 0 0 0 0
>               ACCESS: 1 1 0 116 120 0 0 0
>             READLINK: 0 0 0 0 0 0 0 0
>                 READ: 0 0 0 0 0 0 0 0
>                WRITE: 0 0 0 0 0 0 0 0
>               CREATE: 0 0 0 0 0 0 0 0
>                MKDIR: 0 0 0 0 0 0 0 0
>              SYMLINK: 0 0 0 0 0 0 0 0
>                MKNOD: 0 0 0 0 0 0 0 0
>               REMOVE: 0 0 0 0 0 0 0 0
>                RMDIR: 0 0 0 0 0 0 0 0
>               RENAME: 0 0 0 0 0 0 0 0
>                 LINK: 0 0 0 0 0 0 0 0
>              READDIR: 0 0 0 0 0 0 0 0
>          READDIRPLUS: 0 0 0 0 0 0 0 0
>               FSSTAT: 1 1 0 132 84 0 1 1
>               FSINFO: 1 1 0 132 80 0 0 0
>             PATHCONF: 0 0 0 0 0 0 0 0
>               COMMIT: 0 0 0 0 0 0 0 0
> 
> This format is just awful for parsing.  It's pretty clearly totally
> ad-hoc.  It's not even self-consistent (it uses different separators,
> etc, in the same file!)  It's reasonably compact for human consumption,
> but it doesn't show what the arrays mean.
> 
> Heck, XML would have been better than this mess...

Sigh.  So where where you when I asked for review time and again?

I have a couple of simple Python scripts that can parse this without any 
difficulty.

I resent your tone.  Quite a bit.

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