linux-kernel - Re: About namespaces and unshare() syscall.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Date:	Sun, 03 Mar 2013 14:22:36 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Raphael S Carvalho <raphael.scarv@...il.com>
Cc:	Serge Hallyn <serge.hallyn@...onical.com>,
	linux-kernel@...r.kernel.org
Subject: Re: About namespaces and unshare() syscall.

Raphael S Carvalho <raphael.scarv@...il.com> writes:

> Hi Eric W. Biederman and Serge Hallyn,
>
> I'm a newcomer to Linux kernel Development, and I really like the way
> Linux manages namespaces.
> By the way, I'm studying how copy_process() deals with it. I mean,
> sharing namespaces by default and
> duplicating namespaces on demand. 
> I would appreciate if you can give me tips about where to get started
> (Which areas are needing either help or improvement). 

Public mailing lists are usually good forums for discussion.

> Regarding to unshare syscall, I really care about how the following
> fragment of code will work in the future:
> (kernel/fork.c) static int check_unshare_flags(unsigned long
> unshare_flags):
> ...
> 1735        if (unshare_flags & (CLONE_THREAD | CLONE_SIGHAND |
> CLONE_VM)) {
> 1736                /* FIXME: get_task_mm() increments ->mm_users */
> 1737                if (atomic_read(&current->mm->mm_users) > 1)
> 1738                        return -EINVAL;
> 1739        }
>
> For example, suppose CLONE_VM was added to Unshare syscall, and so you
> created an application which relies on this new feature (Unshare VM).
> So I found your application in the Internet, but I'm running a kernel
> which still has the above checking.
>
> It won't work properly! why?
> Taking a careful look at it, I realized that if one of those flags
> were passed to the unshare syscall and the current process is sharing
> its VM among other processes, the syscall would always return an
> invalid error.
>

Which is exactly correct behavior for threaded applications.
Essentially unshare(CLONE_VM) means make me not a thread.  If
current->mm->mm_users == 1 there is nothing to do.  Otherwise something
has to happen.  And if there is no CLONE_VM support in the kernel 
nothing can happen.

> Conclusion: Your application (relying on Unshare CLONE_VM feature)
> wouldn't work on previous kernel versions since the old
> check_unshare_flags() was programmed so that CLONE_VM (with current
> process sharing its VM) is implicitly an invalid operation. Thus,
> lacking backward compatibility.

Wrong.  You get a nice error telling you that CLONE_VM doesn't work for
threaded applications on the kernel that you are running.

> I also was reading why CLONE_VM was removed from Unshare syscall, it
> seems a core dump could be processing at the same time, so bad things
> might happen. However, it seems this feature will only be implemented
> when really needed.

Which is like most of the kernel.  If someone cares enough to implement
things properly something is implemented.  If no one cares enough the
feature is never implemented, never merged, or never used and removed
when someone notice no one really cares.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/