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 :) -serge _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
