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:	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)

Powered by blists - more mailing lists