linux-kernel - Re: [patch 3/5] VFS: pass open file to ->xattr()

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:	Fri, 21 Sep 2007 15:00:06 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	hch@...radead.org
CC:	miklos@...redi.hu, akpm@...ux-foundation.org, hch@...radead.org,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [patch 3/5] VFS: pass open file to ->xattr()

> On Fri, Sep 21, 2007 at 02:23:46PM +0200, Miklos Szeredi wrote:
> > From: Miklos Szeredi <mszeredi@...e.cz>
> > 
> > Pass the open file into the filesystem's *xattr() methods.
> > 
> > This is needed to be able to correctly implement open-unlink-f*xattr
> > semantics, without having to resort to "silly-renaming".
> > 
> > Do this by adding a 'struct file *' parameter to i_op->*xattr().  For
> > f... variants pass the open file pointer, in other cases pass NULL.
> > 
> > This is safe from a compatibility standpoint, out-of-tree old stuff
> > will continue to work, but will get a warning at compile time.
> 
> NACK, no more optional arguments, and passing file structs to xattr
> stuff is silly.  If your filesystem doesn't get open but unliked
> right you will have to resort to silly renaming, I'm sorry.
> 
> Same argument applies to all pass file down patches in the series,
> I won't comment on the separately.

I don't think it's silly.  Read/write get passed the file descriptor,
and it makes a lot of sense, if the filesystem has stateful opens.

Similarly for any fs operation that gets a file descriptor, it makes
sense to pass the relevant open file down into the filesystem.

If you look carefully, the ftrunacate() already does this, becuse
without that it's impossible to implement correct semantics in the
filesystem in some cases.

For other operations it's not impossible, but it would mean more hacks
in the filesystem itself (such as sillyrenaming) that are entirely
unneeded if the file info is available.

I agree, that the xattr API is quite ugly already, but adding one more
argument won't make it all that much worse.

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/