Quoting Bryan Donlan (bdonlan@xxxxxxxxx): > This is something more of a general question than one about this > manpage, but how will files owned by user namespaces be represented on > the underlying filesystem? Since (C, 501) will be meaningless after a > reboot at the latest, it makes little sense to persist them... Yeah that's a very interesting question. Clearly persistant names for the user namespaces are needed. Eric very much wanted to avoid having the user namespaces be explicitly named, so we pursued the path of having the filesystem handle the naming. So in my last patchset, a mount option could register the mounter's user namespace name. There would be a system-wide policy saying for instance that (B,500) user namespaces owned by can register themselves at C. (end of discussion arising from that patchset is here: ) https://lists.linux-foundation.org/pipermail/containers/2008-August/012793.html In the simplest case of no fs support for user namespaces, the mount will be 'owned' by the userns which mounted it (no persistant name needed for that). Users who are in a different namespace will only get the 'user other' permission to the file/dir, and may not create files there (since we wouldn't know which userid to place on it). Then the fs can support user namespaces - however it wants. It could just store (B, 500),(C, 501) in an xattr. Or it could just store the userid and userns name of the lowest user (I.e. C and 0), and count on knowning that (B, 500) owns user namespace C. We do want to provide generic helpers in lib/fsuserns.c which any fs could use. But yes, picking a meaningful persistant name for a user namespace is an issue. -serge -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
