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();
}
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/containers
