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] [day] [month] [year] [list]
Message-Id: <E1IYpqu-00025I-00@dorka.pomaz.szeredi.hu>
Date:	Fri, 21 Sep 2007 23:15:56 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	adilger@...sterfs.com
CC:	miklos@...redi.hu, hch@...radead.org, trond.myklebust@....uio.no,
	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()

> > 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.
> 
> The read and write operations are DEFINITELY related to the file descriptor
> because of f_pos.  Each process opening the same file can have a different
> f_pos so read/write will work in different locations of the file.

Ah yes, but f_pos is handled entirely within the VFS.  The filesystem
has nothing to do with f_pos, and the read/write methods are passed
the offset explicitly.

So with that the read/write calls (for regular files at least) really
are not that different from fstat.

> In contrast getattr and getxattr operate on the single inode and you don't
> get e.g. a different i_size or i_uid or i_gid depending on who opened a
> file, nor is the xattr different.

You won't get different data either (again for regular files).  Yet
passing file operations down to the filesystem implementation makes
sense even for regular files, even if for most filesystems we could
get away with a totally stateless read/write model (as some other OS's
apparently do).

What I'm arguing, is that if we pass the open file for read/write to
the filesystem for regular files, it makes _equally_ as much sense to
pass the open file for getattr/setattr/xattr operations.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ