linux-kernel - Re: [take 3] pohmelfs: call for inclusion

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:	Wed, 21 Mar 2012 21:54:32 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Evgeniy Polyakov <zbr@...emap.net>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Joe Perches <joe@...ches.com>, greg@...ah.com,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	linux-fsdevel@...r.kernel.org,
	Stephen Rothwell <sfr@...b.auug.org.au>
Subject: Re: [take 3] pohmelfs: call for inclusion

On Thu, Mar 22, 2012 at 01:37:04AM +0400, Evgeniy Polyakov wrote:
> On Wed, Mar 21, 2012 at 09:18:35PM +0000, Al Viro (viro@...IV.linux.org.uk) wrote:
> > I think I've asked that question at least 3 times.  Never got anything
> > resembling an answer...  Is that misspelled dentry_path()?  Or is something
> > subtle going on and we really want different strings generated for
> > chrooted processes here?
> 
> This is a special case which does bad things intentionally.
> http-compatibility was added in _this_ POHMELFS on demand from people
> who do want to access files by handle created from whole path. Not name
> or inode number, but whole path, since that's only what is available in
> http (or more generally via rest api)
> 
> It is limited, wrong and error-prone. It does not even support rename
> and hardlinks. But that's what people want.
> When I bind-remount part of the tree, things 'dissapear' from the tree.
> Yes, this is really an uglymoron, but it was created for _some_ limited
> case which rougly work in sandboxed environment only.

IDGI.  Again, you are getting different strings for different processes,
so that one inside a chroot generates shorter pathnames.  I'm not asking
about races with rename() et.al. - it's obviously racy, but that's a
separate problem.  Details, please - as far as I can tell, that code
looks like a reimplementation of dentry_path() in a curiously broken
way; what demands that particular breakage?  Again, the question of
pathname stability, uniqueness, etc. is a separate story; why this specific
weirdness?  Note that you are passing a to d_path() a vfsmount/dentry
pair that violates all kinds of assertions - dentry->d_sb != mnt->mnt_sb
more often than not, to start with.
--
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/