linux-kernel - vfork() / clone() with pthreads / setuid

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Sat, 21 Jul 2012 01:54:36 +0530
From:	Vishal K <linuxkernelrocks@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: vfork() / clone() with pthreads / setuid

Hello Kernel experts,

>From http://developers.sun.com/solaris/articles/subprocess/subprocess.html
, I am curious to know if the following is already addressed in linux
kernel for vfork() / clone() calls.

The vfork(2) system call was also adopted in the Solaris OS. Much
later, however, when multithreading (MT) became available and widely
used it was discovered that vfork() may introduce a new problem when
the application has multiple threads running: deadlock. The deadlock
can happen due to the dynamic linker ld.so.1 involvement in resolving
the necessary symbols. Particularly, if the child process calls an
external function (such as exec()), the dynamic linker may be invoked
to resolve the Procedure Linkage Table (PLT) entry, for which the
dynamic linker will acquire a mutex lock. This lock may already be
held by a different thread in the parent process. If this happens it
will create a deadlock between the parent and child processes, because
no thread in the parent can run until the child has called exec() or
exit(). As a result, both the parent and the child processes will
hang.

Also, is it allowed to call setuid() after a vfork() or a clone()
before doing execv() so that the executed command can be run as a
different user?

I realize this may not be the right forum for such queries, but looks
like this is not available anywhere.

Regards,
Kernel Rocks.
--
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/