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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 21 Sep 2007 16:59:00 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	hch@...radead.org
CC:	trond.myklebust@....uio.no, miklos@...redi.hu, hch@...radead.org,
	akpm@...ux-foundation.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 10:32:31AM -0400, Trond Myklebust wrote:
> > On Fri, 2007-09-21 at 15:16 +0200, Miklos Szeredi wrote:
> > 
> > > > ftruncate is a special case due to O_TRUNC.
> > > 
> > > No, it's special, because it does not do permission checking, while
> > > truncate() does.
> > 
> > So why not just add file->f_op->ftruncate() and file->f_op->fstat()?
> > Most filesystems can trivially redirect these to do_truncate() and their
> > existing getattr() method. Those, like FUSE, that care can use the hook.
> > In fact, I think that NFSv4 could also benefit from an ftruncate():
> > currently we have to hunt around for an open file context for that
> > particular case.
> 
> Havin the file for fruncate is fine and I'm planning to do something
> along those lines.  Having it for (f)stat is dumb because the operation
> is in no way related to the open file descriptor.

What I'm saying is that read and write are _no_more_ related to the
file than fstat.  Read/write operate on inode data, fstat operates on
inode metadata.

OK, read/write have a position state in the open file, but that is
something the filesystem should _never_ touch anyway, so it's
irrelevant to the discussion.

The fact is, if the filesystem uses a stateful open API, which defines
an fstat() operation, it can be useful to use that instead of the
plain stat().  But that is only possible if the VFS supplies the open
file, otherwise there will be just "hunting around" for suitable open
files, or "sillyrenaming".  None of which is desirable.

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/