Gao feng <gaofeng@xxxxxxxxxxxxxx> writes:
> On 07/02/2013 05:57 PM, Eric W. Biederman wrote:
>> "Daniel P. Berrange" <berrange@xxxxxxxxxx> writes:
>>
>>> On Tue, Jul 02, 2013 at 10:56:37AM +0200, Richard Weinberger wrote:
>>>> Am 02.07.2013 10:44, schrieb Eric W. Biederman:
>>>>> Gao feng <gaofeng@xxxxxxxxxxxxxx> writes:
>>>>>
>>>>>> On 07/02/2013 12:16 AM, Daniel P. Berrange wrote:
>>>>>>> I'm struggling debugging a strange problem with interaction between user
>>>>>>> namespaces, cap_set and ownership of files in /proc/1/
>>>>>>>
>>>>>>
>>>>>> This problem is occured after we call setuid/gid.
>>>>>>
>>>>>> for example, a task whose pid is 1234 calls
>>>>>> setregid(10,10);
>>>>>> setreuid(10,10);
>>>
>>> If seems to get reset to the right values (0:0) when we execve()
>>> the init binary though. This doesn't happen if we have invoked
>>> the capset() syscall in between the setregid & the execve() calls.
>>
>> Yes, execve() should reset the dumpable state.
>>
>> I took a quick look and I don't see a way around set_dumpable calls in
>> setup_new_exec. Why the process remains undumpable after exec is worth
>> investigating. That logic should not be user namespace specific
>> however.
>>
>
> I think it's the install_exec_creds, it calls commit_creds to set process undumpable
>
> /* dumpability changes */
> if (!uid_eq(old->euid, new->euid) ||
> !gid_eq(old->egid, new->egid) ||
> !uid_eq(old->fsuid, new->fsuid) ||
> !gid_eq(old->fsgid, new->fsgid) ||
> !cred_cap_issubset(old, new)) {
> if (task->mm)
> set_dumpable(task->mm, suid_dumpable);
> task->pdeath_signal = 0;
> smp_wmb();
> }
That looks like it could do it. Especially if exec is increasing your
capabilities.
Eric
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/containers
