mbalex has asked for the wisdom of the Perl Monks concerning the following question:

Is it a normal behaviour that you can change the UID of a single thread in perl without effecting the whole process? I've run a perl test program, the main thread creates a new thread which then changes its UID with the subroutine below. I added everywhere a sleep and executed this script as root. Then I saw this process running as root and a new perl thread (thread=process under linux 'top'?) running under the user spezified. This is what I wanted, but I expected that it shouldn't work. But why does it work? 
sub change_uid {
    my $user = shift or die "no user defined";
    my ($uid,$gid) = (getpwnam( $user ))[2,3];
    die "user not found" unless defined $uid;
    $( = $gid;
    $) = $gid;
    $< = $uid;
    $> = $uid;
}

[download]

Replies are listed 'Best First'.
Re: Change UID for threads?
by MarkM (Curate) on Jul 09, 2003 at 01:55 UTC

    I suspect you are executing under Linux, and therefore, I do not find the behaviour you are observing to be surprising.

    Linux has (until recently) implemented threads as separate processes that share the same file descriptors and memory (among a few other things). This behaviour conflicts with the behaviour for threads defined by POSIX.

    More recent thread libraries for Linux, including NPTL honour the POSIX specification much more closely. More recent patches to Linux (some of which are only in the 2.5 stream) modify Linux to work similar to other operating systems (and compatible with POSIX).

    In summary, I suggest that you do not rely on this behaviour, unless you wish to enforce that all of the users of your code remain at the version of Linux and GLIBC that you are currently using to perform your tests.

    Cheers,
    mark

[reply]
      Thank you for your explanation. Since threads are still at "dev"-status (and btw slow on creation in perl), I'll switch to forking processes. Those hopefully work the same on different kernels/implementations. Do they?

      You mentioned that memory is beeing shared when using threads. I could sucessfully change shared memory data as a non-superuser (with this threads-behaviour). But if you now use IPC::Shareable, you are able to set permissions for the shared memory between processes. Is the sharing between processes or threads on the same level (on Linux)? So you possibly could change permissions for thread shared memory as well? I'm just curious about shared memory, because it seems to me to be a good IPC tool.

[reply]

        Threads share memory by using the same virtual memory space. Memory at address 0xDD000000 in one thread is the same memory at address 0xDD000000 in the other thread. If malloc() is executed in one thread, the address can be passed to the other thread, and the other thread can access it as expected.

        IPC shared memory segments are a little different. The memory is registered against an identifier, and exists outside of the address space of the other processes. Processes that use the shm*() controls can map the shared memory segment into their virtual memory. IPC shared memory segments are protected, as you say, with user and group permissions.

        As for which one to use? This is a hard call. It becomes even harder when you bring Perl into the picture, as Perl threads does not allow you to take full advantage of the fact that memory is shared (memory has to be copied from one thread to another, as opposed to accessed in a synchronized manner). Given that you want to use permissions, and have each execution thread running as a different userid, IPC::Shareable may be your only real option.

        Good luck!
        mark

[reply]

Back to Seekers of Perl Wisdom