linux-ext4 - Re: [PATCH] Add a pair of system calls to make extended file stats available [ver #3]

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:	Wed, 07 Jul 2010 16:28:35 +0100
From:	David Howells <dhowells@...hat.com>
To:	Andreas Dilger <adilger@...ger.ca>
Cc:	dhowells@...hat.com, Michael Kerrisk <mtk.manpages@...il.com>,
	linux-fsdevel@...r.kernel.org, linux-cifs@...r.kernel.org,
	linux-kernel@...r.kernel.org, samba-technical@...ts.samba.org,
	linux-ext4@...r.kernel.org, linux-api@...r.kernel.org
Subject: Re: [PATCH] Add a pair of system calls to make extended file stats available [ver #3]

Andreas Dilger <adilger@...ger.ca> wrote:

> I saw your patch to that effect.  I'm of mixed feelings about this, since
> the S_* flags have traditionally been changed on an ad-hoc basis and I don't
> necessarily want to let this leak into the on-disk format of these flags for
> ext*.
> 
> One way to ensure that this holds true is to have a compile-time assertion
> that the respective S_* flags match FS_*_FL and EXT_*_FL.

Something like this:

	#if S_SYNC != FS_SYNC_FL               ||      \
	       S_IMMUTABLE != FS_IMMUTABLE_FL  ||      \
	       S_APPEND != FS_APPEND_FL        ||      \
	       S_NOATIME != FS_NOATIME_FL      ||      \
	       S_DIRSYNC != FS_DIRSYNC_FL
	#error Ext2/3/4 assumes these equivalences
	#endif

would do the trick.

> > (5) How often are these flags required?  E.g. does it make more sense to
> >   keep them as an additional result, or does it make sense to stick them
> >   in the kstat and xstat structs, knowing that these are allocated on the
> >   kernel stack maybe as three times if an ecryptfs file?
> 
> If they aren't requested by userspace, the cost is mostly irrelevant.  I
> think on OSX these flags are returned for every "ls" call, to mark the
> inodes with xattrs every time.

I suppose.  I was thinking that they may have to be retrieved from the server.

More concerning to me is the effect of adding more fields to the kstat struct.

Nonetheless, having these flags around may be useful to CIFS, Samba, NFS and
NFSD as various of them may appear in those protocols.  Certainly, SMB passes
a bit indicating compression around (ATTR_COMPRESSED).

David
--
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