On 3/27/2012 6:10 AM, David Quigley wrote:
> On 03/27/2012 00:38, Casey Schaufler wrote:
>> On 3/26/2012 7:22 AM, David Howells wrote:
>>> J. R. Okajima <hooanon05@xxxxxxxxxxx> wrote:
>>>
>>>>> (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,
>>> True. I'm not sure what's the best way to deal with that. Possibly
>>> add an
>>> extra flag to vfs_setxattr() and have the fs vet them... OTOH, this
>>> gives us
>>> files on the lowerfs that may well differ in appearance to files on the
>>> upperfs with respect to their xattrs.
>>
>> Are you suggesting that you would have heterogeneous filesystems
>> with different xattr behavior stacked at the same time as you're
>> using an LSM that cares about the behavior of xattrs? Oh dear. As
>> I typed that sentence I identified a viable use case.
>
> The most common use case for union mounts is a livecd. In this case
> the livecd iso has a tmpfs rw mount above it for copyup. I don't know
> how useful having a smart xattr copyup mechanism is in that place as
> most of the labels will be whatever is assigned to the iso. Another
> usecase is snapshotting of a filesystem for rollback. In this case it
> is probably important to retain the existing label as the copyup is
> supposed to be to the same location. The last case which is similar to
> the snapshotting case but with a persistant upper branch would be to
> have an NFS mount and have local configuration changes stored locally.
> In that case as well I can see simple copy up as being ok to do since
> you're using it more as an overlay than a union mount.
>
> Now the tricky case is when you have two filesystems with two
> different directories with the same name. You're going to merge those
> namespaces. The problem occurs when the parent directories have
> different labels.
>
> For example /mnt/upper/foo is labeled foo_t and /mnt/lower/foo is
> labeled foo2_t. What do you use for the label for files created in
> /mnt/union/foo?
The label for the directory on the filesystem on which the file
physically resides.
If all of the filesystem secede from the union, whichever directory will
be the
file's parent.
>
>>
>>>> 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.
>>> Also true. It's possible that the best way is just to ignore
>>> everything but a
>>> medium-related error such as EIO, ENOSPC and EDQUOT: We tried... Oh
>>> well.
>>>
>>>> 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.
>>> Yeah. Ideally, the copied-up file would be indistinguishable from
>>> the lower
>>> file, but in practice that's not possible unless inode numbers and
>>> other
>>> physical characteristics of the lower file are recorded in the upper
>>> fs (say
>>> on an xattr).
>>>
>>>> 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
>>> I would suggest 'cpyup' or 'copyup' rather than 'cpup' - the latter
>>> looks like
>>> something to do with CPUs, but yes, it's worth considering.
>>>
>>>> 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.
>>> That's not necessarily good enough. What if and LSM, say SELinux,
>>> is in
>>> force? Now SELinux will happily label the files for you - but
>>> there's a
>>> reasonable chance they won't be correct. OTOH, they may not be
>>> correct even
>>> if they are copied up.
>>
>> The underlying storage (the "real" file) has to have the xattr attached
>> to it.
>> Any other behavior is incorrect. If the underlying filesystem does not
>> support
>> xattrs that lack of support has to be propagated upwards even if the
>> higher
>> layer filesystem supports xattrs.
>>
>> In the case of Smack filesystems that don't support xattrs are still
>> given
>> labels based on mount options. If the lower filesystem is NTFS and
>> the upper
>> ext4 you've got to respect the NTFS labeling behavior for files there.
>>
>>>> Does union-mount preserve mtime? If not, it is critical for some
>>>> applications such like "make" I am afraid.
>>> Ummm... Interesting question. If it copies up a file, then that
>>> file must
>>> have been opened for writing. Is the mtime altered by such an
>>> event, or only
>>> by a write() having been issued? Also, what about ctime? That
>>> doesn't seem
>>> to have been copied up either.
>>
>> What is the expected behavior of union mounts for all attributes? Is it
>> specified anywhere?
>>
>
> I would assume its under their documentation patch. I tried to lookup
> up what we did for our copyup semantics for file attributes. Its not
> simple or straight forward in the original UnionFS. I think its safe
> to say all the first class attributes need to be copied up. When
> possible we also copied the xattrs as well. Its important to realize
> though that union mounts are namespace unification and not
> fileunification so if you copy one xattr up you need to copy them all
> because any that don't get copied will get left behind.
>
>>>
>>> David
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe
>>> linux-kernel" in
>>> the body of a message to majordomo@xxxxxxxxxxxxxxx
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at http://www.tux.org/lkml/
>>>
>>
>>
>> --
>> This message was distributed to subscribers of the selinux mailing list.
>> If you no longer wish to subscribe, send mail to
>> majordomo@xxxxxxxxxxxxx with
>> the words "unsubscribe selinux" without quotes as the message.
>
>
--
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
