linux-ext4 - Re: [PATCH, RFC V3] ext3: add ioctl to force 32-bit hashes from indexed dirs

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:	Sat, 06 Apr 2013 10:05:25 +1100
From:	Andrew Bartlett <abartlet@...ba.org>
To:	Anand Avati <avati@...hat.com>
Cc:	Eric Sandeen <sandeen@...hat.com>, Theodore Ts'o <tytso@....edu>,
	ext4 development <linux-ext4@...r.kernel.org>,
	Jan Kara <jack@...e.cz>,
	"J. Bruce Fields" <bfields@...hat.com>, gluster-devel@...gnu.org,
	jra@...ba.org
Subject: Re: [PATCH, RFC V3] ext3: add ioctl to force 32-bit hashes from
 indexed dirs

On Mon, 2013-04-01 at 13:34 -0700, Anand Avati wrote:
> On Apr 1, 2013, at 1:05 PM, Eric Sandeen <sandeen@...hat.com> wrote:
> > 
> > Meh, let's just keep it simple then.  And I'd really like to know if
> > gluster still even needs this, or if their new scheme will work instead,
> 
> As of this morning the new d_off transformation (Zach's idea) is merged in gluster. We had to put in some kind of ext4 awareness, and the "more complex" d_off transformation (which is finally working properly after fixing some minor issues) seemed better than calling ioctls by detecting the backend is ext4.
> 
> > in  which case we should drop it - but Samba made noise about needing it too,
> > though I've not seen specifics, so I hate to merge it "just in case."
> 
> Yes, I too saw comments from Andrew Bartlett of the Samba team. It
> appeared to be the case that Samba could only present 32bit cookies
> while ext4 was now returning larger cookies (somewhat like the old
> NFSv2 clients problem?). This ioctl would be useful there I guess,
> bring it "in par" with knfsd's abilities of expressing desire for
> 32bit cookies? However, for knfsd legacy requirements, FMODE_32BITHASH
> is in generic VFS. But for a userspace file server, it would need to
> first gain the knowledge of which filesystems in the world actually
> present large cookies, and for the subset which support smaller
> cookies, issue filesystem specific ioctls() in their own specific
> ways.
> 
> Wouldn't it be "fair" to treat userspace file servers as equals, and
> provide a generic FS independent ioctl to set the common
> FMODE_32BITHASH flag on any dir fd? Think of it as a way of extending
> the "pointer access" to file->f_mode which NFS exercises, up to
> userspace?

If 32-bit cookies are baked into current-generation NFS, even if Samba
doesn't take this up, wouldn't
http://sourceforge.net/apps/trac/nfs-ganesha/ need it just the same?

Samba's use case fortunately is for DOS clients, and there just are not
very many of those any more (and tests that behave like dos clients,
which is how we noticed). 

You CC'ed Jeremy, who is our authority on this area (I just noticed and
inquired into the failing tests).  I'm hoping he can give a more
authoritative view on if we would push for this. 

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org


--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html