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]

Message-ID: <4859.1278341989@redhat.com>
Date:	Mon, 05 Jul 2010 15:59:49 +0100
From:	David Howells <dhowells@...hat.com>
To:	Michael Kerrisk <mtk.manpages@...il.com>
Cc:	dhowells@...hat.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]

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

I've also been asked to provide st_flags as for BSD, which aren't compatible
either:-/.

Some questions:

 (1) Does it make sense to rearrange the S_xxxx flags to match the numbers for
     FS_xxxx_FL?

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

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

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

> * Return a bit mask indicating the presence of additional information
> associated with the i-node. Here, I am thinking of flags that indicate
> that the file has any of the following: capabilities, an ACL, and
> extended attributes (obviously a superset of the previous). I could
> imagine some apps that, having got the xstat info, would be interested
> to obtain some of this other info.
> 
> Obviously, the above only make sense if the overhead of providing the
> extra information is low.

That might make sense as an 'additional result'.  These things may have to be
probed for on disk or on a server, so you might not want to return them by
default, and you may want to indicate what the filesystem can support vs what
the file actually has:

	u64	st_fs_additional_info;	/* what the filesystem supports */
	u64	st_file_additional_info; /* what the file actually has */

	#define XST_ADDINFO_CAPABILITY_MASK
	#define XST_ADDINFO_ACL
	#define XST_ADDINFO_XATTRS
	#define XST_ADDINFO_SECLABEL

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