Miklos Szeredi <miklos@szeredi.hu> writes:>> > The> were invented for.For the print statement? What ever it is minor.>> >> interface. As it is, we cannot be sure, that existing callers of> mount(2) don't have fsuid set to some random value.If we can get away without an extra flag it would really bepreferable.In the container case we have an interesting and very commonscenario struct user *our_user != &root_user. our_user->uid == 0.I.e. The root in the what is the container but not the rootof the entire system.So I want to minimize the changes needed to existing programs.Now if all we have to do is specify MS_SETUSER when root auser with CAP_SETUID is setting up a mount as a user otherthen himself then I don't much care. If we have to call MS_SETUSERas unprivileged users I will have to modify mount binaries to workdifferently inside and outside of containers.Further there is only one or two versions of mount in widespreaduse on linux, and unless you do something special fsuid == euid.So the chance of fsuid set to some random value is pretty low.So yes I think we can be 99.9% certain that existing callers ofmount(2) don't have fsuid set to some random value just byinspecting the code of mount(1).>> >  than> treating user=0 mounts special.I don't think we should treat any mount special and all mountsshould be owned.>> > +>> > +?In the uid namespace the comparison is simpler as are the propagationsrules. Basically if you use a struct user you will never need tocare about a uid namespace. If you don't we will have to tear throughthis code another time.Plus like I was mentioning earlier. If we do have a struct user thereimplementing per user mount rlimits becomes trivial.Eric-To unsubscribe from this list: send the line "unsubscribe linux-kernel" inthe body of a message to majordomo@vger.kernel.orgMore majordomo info at read the FAQ at