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]

Message-Id: <E1IYiN2-0001eq-00@dorka.pomaz.szeredi.hu>
Date:	Fri, 21 Sep 2007 15:16:36 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	hch@...radead.org
CC:	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()

> > 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.
> 
> read/write fundamentally operate on file descriptors.  None of these
> operations does, rather their normal forms get a path name and special
> forms operate on a file descriptor to avoid lookup races.  Still the
> underlying operation has nothing to do with the file descriptor at all.

I don't see why read/write are special, "normal" filesystems don't
need the file descriptor in that case either.

And other in BSD's, OS X, the read/write fs ops don't get the open
file, and their fuse implementations have to hack around this.

The exact same thing is true for the other operations on file
descriptors, just in those cases Linux does the same as the other
OS's.

> > 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.
> 
> ftruncate is a special case due to O_TRUNC.

No, it's special, because it does not do permission checking, while
truncate() does.

> > 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.
> 
> It's not a problem at all for filesystem that implement normal unix
> semantics.  If you want to shoer-horn strange semantics that barely
> fit, you'll need some more hacks.

What about sshfs.  Basically it uses the sftp protocol, which more or
less implements the UNIX API in a remote protocol.

So it has OPEN, READ, WRITE, CLOSE, STAT, FSTAT, etc. operation.  Now
why is FSTAT different than READ or WRITE?

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/