lkml.org 
[lkml]   [2009]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: C/R review


Serge E. Hallyn wrote:
> Quoting Alexey Dobriyan (adobriyan@gmail.com):
>>> +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.


\
 
 \ /
  Last update: 2009-03-18 10:47    [W:0.065 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site