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
too.
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
--preserve=mode,ownership,timestamps,context,links,xattr,all
('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
cpup-xattr=acl,context,all
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-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
