Serge E. Hallyn wrote: > Quoting Alexey Dobriyan (adobriyan@xxxxxxxxx): >>> +Keeping the restart procedure to operate within the limits of the >>> +caller's credentials means that there various scenarios that cannot >>> +be supported. For instance, a setuid program that opened a protected >>> +log file and then dropped privileges will fail the restart, because >>> +the user won't have enough credentials to reopen the file. >> That's a bug. > > What is described is not a bug, but I think the way it is done is in > fact a bug. > > Note that just because you *can* do the restart without privilege > doesn't mean that you have to. If you do a restart with privilege, > then you should be able to open that file, then drop down to the > original task's uid. > > But to say that letting an unprivileged user do restart, and that > it will only succeed if it can access the resources its allowed to > access, is bogus. > > But I do think the way it's implemented will become buggy and needs to > be fixed. That is, we do cr_read_task_struct() before we do > cr_read_files(). So in fact if I'm root doing restart of such a > checkpoint image, I'll first drop down to uid 500, then open the files. > > That would obviously be a bug. > > Now, we don't actually restore uids yet in the current code, so > it's still a theoretical bug :) Good point. And that's why uid's will be restored at the end :) (when we get there ...) Oren. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
