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, 17 Oct 2012 12:25:46 +0900
From:	Jaegeuk Kim <jaegeuk.kim@...sung.com>
To:	'Dave Chinner' <david@...morbit.com>,
	'Jaegeuk Kim' <jaegeuk.kim@...il.com>
Cc:	'Arnd Bergmann' <arnd@...db.de>,
	'Vyacheslav Dubeyko' <slava@...eyko.com>,
	viro@...iv.linux.org.uk, 'Theodore Ts'o' <tytso@....edu>,
	gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
	chur.lee@...sung.com, cm224.lee@...sung.com,
	jooyoung.hwang@...sung.com
Subject: RE: [PATCH 11/16] f2fs: add inode operations for special inodes

> On Wed, Oct 17, 2012 at 07:30:21AM +0900, Jaegeuk Kim wrote:
> > > > > OTOH, I think xattr itself is for users, not for communicating
> > > > > between file system and users.
> > > >
> > > > No, you are mistaken in that point, as Dave explained.
> > >
> > > e.g. selinux, IMA, ACLs, capabilities, etc all communicate
> > > information that the kernel uses for access control. That's why
> > > xattrs have different namespaces like "system", "security" and
> > > "user". Only user attributes are truly for user data
> > > - the rest are for communicating information to the kernel....
> > >
> >
> > I agree that "system" is used by kernel.
> > How about the file system view?
> 
> Not sure what you mean - the filesystem woul dsimply read the xattrs
> in the system namespace as it needs, just like the other subsystems
> like selinux or IMA do.
> 
> > Would you explain what file systems retrieve xattrs and use
> > them with their own purpose?
> 
> I think cachefs users a "CacheFiles.cache" namespace for storing
> information it needs in xattrs. ecryptfs stores crypto metadata in
> xattrs in the lower filesytem. NFSv4 servers store junction mount
> information in xattrs.
> 
> So there are examples where filesystems use xattrs for special
> information. However, in most cases filesystems don't need xattrs
> for their own metadata primarily because that gets added to their
> own on-disk formats. IThe above are all "overlay" style filesystems
> that don't have their own on-disk formats, so need to use xattrs to
> store their per-inode metadata.
> 
> The case of access hints and allocation policies are not somethign
> that are native to any filesystem on-disk format. They are abstract
> concepts that really only the software generating/using that
> information knows about. Given we want the software that uses this
> information to be in VFS, it is separate from every filesystem and
> this is exactly the use case that system xattrs were intended for.
> :)

I understand. Thank you very much. :)

> 
> > Sorry, I'm not familiar with xattrs in depth.
> >
> > Unfortunately, "system" is not implemented in f2fs yet. :(
> 
> If you've already implemented the user.* namespace, then it's
> trivial to support the other namespaces - it's just prefixing the
> xattrs with the appropriate string instead of "user"....
> 

Ok, I'll do right now.
Thanks, again.

> Cheers,
> 
> Dave.
> --
> Dave Chinner
> david@...morbit.com

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ