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  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:	Sun, 26 Feb 2012 15:48:33 +0900
From:	"J. R. Okajima" <>
To:	David Howells <>
Subject: copy-up xattr (Re: [RFC][PATCH 00/73] Union Mount [ver #2])

David Howells:
>  (4) Added some code to override the credentials around upper inode creation
>      to make sure the inode gets the right UID/GID.  This doesn't help if the
>      lower inode has some sort of foreign user identifier.
>      Also, I'm not sure whether the LSM xattrs should be blindly copied up.
>      Should the LSM policies applicable to the lower fs's apply to the upper
>      fs too?

Obviously the xattr entry may not have its meanings on the upper fs, or
the upper fs may return an error when setting the xattr. Additionally
the returned errno may not follow the generic semantics (ENOTSUP,
ENOSPC, or EDQUOT) since the fs may return fs-specific error.
On the other hand, users may expect that the all xattrs are copied-up,
particulary when he knows that the xattrs works well on the upper fs
In copy-up, it will be hard to support all cases.

In order to leave users how to handle the xattrs, I'd suggest
introducing some mount options, which are similar to cp(1).
cp(1) has several options
	('mode' includes acl which are based upon xattr)

Since the mode (without acl), ownership and timestamps should always be
copied-up, the new mount options will be something like

And only when the option is specfied, the xattrs are copied up. No
special error handling is necessary, all the errors should be returned
to users unconditionally.

Does union-mount preserve mtime? If not, it is critical for some
applications such like "make" I am afraid.

J. R. Okajima
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists