linux-kernel - 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, 7 Jul 2010 08:57:54 -0600
From:	Andreas Dilger <adilger@...ger.ca>
To:	David Howells <dhowells@...hat.com>
Cc:	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]

On 2010-07-05, at 08:59, David Howells wrote:
> Michael Kerrisk <mtk.manpages@...il.com> wrote:
> 
>> * Include information from the "inode_info" structure, most notably
>> i_flags, but perhaps other info as well.
> 
> This thought has occurred to me, but are the contents of i_flags identical for
> all filesystems?  Certainly, i_flags doesn't seem to match the FS_IOC_GETFLAGS
> mask.  For example:
> 
> 	#define	FS_SECRM_FL			0x00000001
> 
> vs:
> 
> 	#define S_SYNC		1	/* Writes are synced at once */
> 
> (1) Does it make sense to rearrange the S_xxxx flags to match the numbers for
>   FS_xxxx_FL?

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.

We use a macro in Lustre for compile-time assertions that depends on the detection of duplicate values in a switch() statement:

/** Compile-time assertion.
* Check an invariant described by a constant expression at compile time by
* forcing a compiler error if it does not hold.  @cond must be a constant
* expression as defined by the ISO C Standard:
*
*       6.8.4.2  The switch statement
*       ....
*       [#3] The expression of each case label shall be  an  integer
*       constant   expression  and  no  two  of  the  case  constant
*       expressions in the same switch statement shall have the same
*       value after conversion...
*
*/
#define CLASSERT(cond) do {switch(42) {case (cond): case 0: break;}} while (0)

> (2) Does it make sense to do the BSD st_flags compatibility in userspace?
> 
> (3) Can we add a couple more flags to make Samba's life easier?  Say an
>   archived bit and a hidden bit?

I wouldn't object to that.  The BSD flags indicate that the hidden bit should only affect GUI display managers, not "ls".

> (4) Do I actually need to provide a mask saying what st_flags are applicable
>   to the file you've just queried?

Hmm, good question.

> (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.

Cheers, Andreas

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