linux-kernel - Re: [patch 4/6] vfs: mountinfo show dominating group id

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: <E1Jby0n-0002Tc-Gb@pomaz-ex.szeredi.hu>
Date:	Wed, 19 Mar 2008 14:07:21 +0100
From:	Miklos Szeredi <miklos@...redi.hu>
To:	viro@...IV.linux.org.uk
CC:	miklos@...redi.hu, akpm@...ux-foundation.org, linuxram@...ibm.com,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [patch 4/6] vfs: mountinfo show dominating group id

> > > So maybe some alternative, multi line format would be better?
> > > 
> > > MountID: 99
> > > ParentID: 88
> > > DevID: 0:34
> > > Type: foofs
> > > Source: /dev/foo
> > > Root: /
> > > MountPoint: /mnt/foo
> > > MountOpts: rw,noatime
> > > Opts: rw,errors=continue
> > > Propagation: shared:42
> > 
> > Which still doesn't fully solve the problem, since ->show_options()
> > can also spew newlines + MountID:.  Oh well.
> 
> a) ban newlines in ->show_options(); that's a requirement that is easy
> to formulate and understand, so it has a chance to survive the contact
> with reality.
> 
> b) the order is all wrong - *everything* that depends on fs type should
> be after fs type and everything else should be prior to it.  That way
> you don't need to know what the hell does this fs type spew in order to
> parse type-independent information.  In particular, "source" (BTW, why
> do you capitalize those?) certainly has no business being in front of
> fs type; as the matter of fact, I'm not at all sure that we _want_ it
> separated from the rest of type-dependent options.  The fact that mount(2)
> gets it in a separate argument is a historical accident...
> 
> c) since you are tagging the fields anyway, why do you need newlines?
> Moreover, you don't really need to tag everything - there's a well-defined
> beginning and optional fields between it and (type+rest) are the only
> things that needs to be tagged...  BTW, why bother with Propagation: part
> and gluing shared:... with slave:... into a single field?  Separate them
> with whitespace - you have recognizable prefixes right there.
> 

99 88 0:34 / /mnt/foo rw,noatime shared:42 slave:13 foofs /dev/foo,errors=continue

Something like that?  It assumes, that fs types never have ':' in
them, but that's acceptable.

Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/