linux-kernel - Re: [nameidata 1/2] Don't pass NULL nameidata to vfs

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:	Mon, 16 Apr 2007 17:21:46 +0100
From:	Christoph Hellwig <hch@...radead.org>
To:	Andreas Gruenbacher <agruen@...e.de>
Cc:	Christoph Hellwig <hch@...radead.org>, jjohansen@...e.de,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, chrisw@...s-sol.org,
	Tony Jones <tonyj@...e.de>
Subject: Re: [nameidata 1/2] Don't pass NULL nameidata to vfs_create

On Mon, Apr 16, 2007 at 06:11:30PM +0200, Andreas Gruenbacher wrote:
> On Thursday 12 April 2007 12:06, Christoph Hellwig wrote:
> > Once again very strong NACK.  Every conditional passing of vfsmounts get my
> > veto.  As mentioned last time if you really want this send a patch series
> > first that passed the vfsmount consistantly.
> 
> I don't consider it fair to NACK this patch just because some other part of 
> the kernel uses vfs_create() in the wrong way -- those are really independent 
> issues. The bug is not that hard to fix though; here is a proposed patch on 
> top of the other AppArmor patches.

Note that it's not just this particular hunk, all these kinds of conditional
passing are wrong.

> 
> The offenders are nfsd and the mqueue filesystem. Instantiate a struct 
> nameidata there.
> 
> The .dentry and .mnt fields can easily be filled in in nfsd. The mqueue 
> filesystem is somewhat special: files that mq_open creates are on an internal 
> mount and the mqueue filesystem is not generally visible (it may or may not 
> be mounted). When passing a regular vfsmount to vfs_create the files would 
> appear disconnected while they actually are kernel-internal objects. Use a 
> NULL vfsmount there to avoid that -- passing the kernel-internal vfsmount 
> there wouldn't help, anyway.

But anyway, creating fake nameidata structures is not really helpful.
If there is a nameidata passed people expect it to be complete, and
if you pass them to an LSM people will e.g. try to look into lookup
intents.  But similar to the per-mountpoint r/o work I suspect you're
simply operating on the wrong level, but then again this might not
be fixable due to the braindead apparmor design.
-
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/