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

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

Date:	Thu, 22 Mar 2012 02:04:15 +0400
From:	Evgeniy Polyakov <zbr@...emap.net>
To:	Al Viro <viro@...IV.linux.org.uk>
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 Wed, Mar 21, 2012 at 09:54:32PM +0000, Al Viro (viro@...IV.linux.org.uk) wrote:
> 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

http_compat ugly mount options forbids rename
It cuts fair amount of functionality present for 'normal' pohmelfs

> 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.

Details are pretty simple - we want to allow external applications to
get to filesystem and grab data via single requests, since it is
stateless and can not hold dentry structure. They do not connect to
server which runs on top of filesystem, but insted directly to storage,
which hosts raw data.

Applications know they uploadede data via /whatever/path/was/to/the/file
And they want to get that data from server via single 'get'. Obviously
they can not store mapping from all filenames to inode number, and they
can not request dozen of directory lookups, since it takes time and has
to maintain state.

When object was written via remounted path, then it is a problem for
those who made a setup - this ugly hack only 'works' in specially
crafted environment, which provides its pros and requires fair price of
cons.

Generic POHMELFS does not require this compatibility mode.

-- 
	Evgeniy Polyakov
--
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/