On czw, 2014-11-27 at 10:44 -0600, Eric W. Biederman wrote: > Lukasz Pawelczyk <l.pawelczyk@xxxxxxxxxxx> writes: > > > On czw, 2014-11-27 at 09:42 -0600, Eric W. Biederman wrote: > >> We are probably going to need to go a couple rounds with this but at > >> first approximation I think this functionality needs to be tied to the > >> user namespace. This functionality already looks half tied to it. Actually it's not. You can create LSM/Smack namespace without user namespace and it works properly. > >> When mounting filesystems with user namespaces priveleges matures a > >> little more you should be able to use unmapped labels. In the near term > >> we are looking at filesystems such as tmpfs, fuse and posibly extN. Ok, I get the idea now. But still think it wouldn't do well with the Smack namespace. It would basically allow you to operate on something that the administrator did not allowed you to (by filling the labels' map). If the user namespace allows such a thing now I was not aware. I'll have a look. > I had two points. > a) Tie the label mapping to the user namespace, then we don't need any > new namespaces. > > Is there a reason not to tie the label mapping to the user namespace? I remember that I entertained the idea when I started the work on that and for some reason went against it. Right now the major issue I see is that LSM by itself is not defined how it's going to behave. It's up to a specific LSM module. E.g. within the Smack namespace filling the map is a privileged operation. So by tying them up you cripple the ability to create a fully working user namespace as an unprivileged process. I want to have Smack namespace be able to map its own label without privileges (as user namespace can do with its own UID) but for now it's not the case and I'm not sure it will ever be. With other LSM implementation other limitations might apply. Besides a use case (with other LSM modules) when someone might not want to create an LSM namespace might be valid as well. > > Needing to modify every userspace that create containers to know > about every different lsm looks like a maintenance difficulty I would > prefer to avoid. The LSM namespace is only one, it's not like every LSM modules creates a different namespace. The LSM namespace is created for the LSM module that is active at the moment. And user space might need to be aware of them anyway as e.g. Smack requires you to create labels' map. Other modules might require something different. BTW: have you read the Smack-namespace readme I pasted in the cover letter? It describes the idea behind namespace implementation in that particular module. -- Lukasz Pawelczyk Samsung R&D Institute Poland Samsung Electronics -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
