Dave Hansen <dave@xxxxxxxxxxxxxxxxxx> writes: >> I was thinking about restore. Creating objects with a certain id can >> easily be a security risk if you are not creating the namespace those >> objects live in at the same time. There is currently the downside >> that we can't create namespaces as unprivileged users ( The >> implementation of suid is so annoying). But the general concept still >> applies, and if we ever get the uid namespace correct we will be able >> to create namespaces as unprivileged users. > > Eric, you were saying that my interface had way too many "dangerous > syscalls". How does this relate to user namespaces and creating objects > with particular ids? Surely if the true problem with my suggested > approach has to do with creating empty namespaces, the same problem > exists with the sys_checkpoint() approach. Ok. Some concrete examples to put this in context. First the class of problem I am talking about is the classic unix temp file security hole. A specific example is fork_and_set_child_pid(); Suppose there is a important system daemon that dies and it's pid is 23. It dies and doesn't delete it's pid file. A malicious user notices this and does for_and_set_child_pid(23); Later someone checks to see if the important system daemon is running, sees a process at pid 23, and so does not restart it. A DOS attack. In a sys_restore() scenario at the very start you can check to make certain that the reference count for the namespaces is 1 and that they are empty. Which means there is no chance of confusing user space. With fork_and_set_child_pid() what is a simple cheap one time check becomes an expensive painful one, if you can even implement it at all. The difference is that with a bunch of small pieces you loose atomicity. Eric _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers