linux-ext4 - Re: [PATCH 02/12] statx: Provide IOC flags for Windows fs attributes

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: <591F46C1-DBA1-434A-9BD1-1D45DD94611B@dilger.ca>
Date:	Thu, 26 Nov 2015 15:10:16 -0700
From:	Andreas Dilger <adilger@...ger.ca>
To:	David Howells <dhowells@...hat.com>
Cc:	Theodore Ts'o <tytso@....edu>, arnd@...db.de,
	linux-afs@...r.kernel.org, linux-nfs@...r.kernel.org,
	linux-cifs@...r.kernel.org, samba-technical@...ts.samba.org,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-ext4@...r.kernel.org
Subject: Re: [PATCH 02/12] statx: Provide IOC flags for Windows fs attributes

On Nov 26, 2015, at 8:35 AM, David Howells <dhowells@...hat.com> wrote:
> 
> Theodore Ts'o <tytso@....edu> wrote:
> 
>> As a result, I would suggest that we not try to use the
>> FS_IOC_[GS]ETFLAGS number scheme for any new interface, so we're at
>> least not making a bad situation worse.
>> 
>> The only reason why some other file systems have chosen to use
>> FS_IOC_[GS]ETFLAGS, instead of defining their own ioctl, is so they
>> can use lsattr/chattr from e2fsprogs instead of creating their own
>> utility.  But for statx, there isn't a good reason use the same flags
>> number space.  At the very least, can we use a new flags field for the
>> Windows file attributes?  It's not like lsattr/chattr has the ability
>> to set those flags today anyway.  So we might as well use a new flags
>> field and a new flags numberspace for them.
> 
> Hmmm...  I was trying to make it so that these bits would be saved to disk as
> part of the IOC flags so that Samba could make use of them.  I guess they'll
> have to be stored in an xattr instead.

The flags can be part of the same flags word in the statx() API, and how they
are stored on disk is a filesystem implementation detail.  In some cases, not
all of the flags can be stored on disk (e.g. FAT or whatever) and an error
will be returned.  In other cases they can be stored efficiently as bits in
the inode, and other filesystems may chose to store them as internal xattrs.
That shouldn't be the concern of the statx() syscall.

Cheers, Andreas






Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)