http://www.perlmonks.org?node_id=791479

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

Hi

I'm trying to run a script that changes my effective user id. The permissions are 6550 (-r-sr-s---) owner = root, and I'm running the script as a member of the group that is given group execute permissions.

#!/usr/bin/perl -T use strict; my $user = 'etl'; my $group = 'etl'; my $uid = getpwnam($user) || die "Cannot identify uid"; my $gid = getgrnam($group) || die "Cannot identify gid"; printf("Current Effective User ID: %s\n", $>); printf("Current Effective Group IDs: %s\n", $)); printf("Requested User ID: %s\n", $uid); printf("Requested Group ID: %s\n", $gid); print "Changing Effective IDs\n"; $> = $uid; $) = $gid; printf("Current Effective User ID: %s\n", $>); printf("Current Effective Group IDs: %s\n", $));

When the script as run as myself, the output is:

Current Effective User ID: 500 Current Effective Group IDs: 500 500 Requested User ID: 502 Requested Group ID: 503 Changing Effective IDs Current Effective User ID: 500 Current Effective Group IDs: 500 500

Note the effective ids haven't changed. However, when I run the script as root, the effective user id is what I requested, although the group ids haven't changed

Current Effective User ID: 0 Current Effective Group IDs: 0 0 1 2 3 4 6 10 Requested User ID: 502 Requested Group ID: 503 Changing Effective IDs Current Effective User ID: 502 Current Effective Group IDs: 0 0 1 2 3 4 6 10
So my question is: how do I change my effective user id? I'm using Perl 5.10.0 on Centos 5.3 Thnanks

Replies are listed 'Best First'.
Re: Changing effecive user id
by Crackers2 (Parson) on Aug 27, 2009 at 01:05 UTC

    For the second part "group ids haven't changed", you need to reverse the order of your assignments, since once you've changed your UID you probably don't have enough permissions anymore to change the GID.

    For the first part, my perl gives me a

    $ /tmp/k Can't do setuid (cannot exec sperl)
    error so I can't quite test it.

    Update: I installed perl-suidperl so now it works. It looks like the setuid bits aren't working for you, since the effective UID/GID when run as yourself should still show as root if the file is owned by root and has the setuid bit set:

    $ id -u 1000 $ id -g 1000 $ /tmp/k Current Effective User ID: 0 Current Effective Group IDs: 1000 1002 1001 1000 Requested User ID: 1001 Requested Group ID: 55 Changing Effective IDs Current Effective User ID: 1001 Current Effective Group IDs: 55 1002 1001 1000

      Thanks. Ok - I added perl-suid to the vendor (Redhat/CentOS) Perl and it now works. However, I still need to get it working with my hand-compiled Perl

      According to perlsec:

      In recent years, vendors have begun to supply systems free of this inherent security bug. On such systems, when the kernel passes the name of the set-id script to open to the interpreter, rather than using a pathname subject to meddling, it instead passes /dev/fd/3. This is a special file already opened on the script, so that there can be no race condition for evil scripts to exploit. On these systems, Perl should be compiled with -DSETUID_SCRIPTS_ARE_SECURE_NOW . The Configure program that builds Perl tries to figure this out for itself, so you should never have to specify this yourself.

      So I'm guessing RHEL/CentOS 5.3 doesn't support this. But your reply got me wondering whether I should be adding suid perl to my build. The perl 5.10.0 INSTALL file doesn't mention it, other than it will be deprecated in favour of the SETUID_SCRIPTS_ARE_SECURE_NOW option that doesn't seem to be working for me. So it seems I should revert to suidperl. I couldn't see any instructions on how to do this in the INSTALL file. This didn't work for me:

      make make suidperl make test make install

      suidperl got created in the build directory, but the install didn't seem to do anything with it...

      Cheers

        Ok, may way forward was to run Configure in interactive mode:
        Some kernels have a bug that prevents setuid #! scripts from being secure. Some sites have disabled setuid #! scripts because of this. First let's decide if your kernel supports secure setuid #! scripts. (If setuid #! scripts would be secure but have been disabled anyway, don't say that they are secure if asked.) If you are not sure if they are secure, I can check but I'll need a username and password different from the one you are using right now. If you don't have such a username or don't want me to test, simply enter 'none'. Other username to test security of setuid scripts with? [none] <my use +rname> "su" will (probably) prompt you for <my username>'s password. I don't think setuid scripts are secure. Does your kernel have *secure* setuid scripts? [n] Some systems have disabled setuid scripts, especially systems where setuid scripts cannot be secure. On systems where setuid scripts have been disabled, the setuid/setgid bits on scripts are currently useless. It is possible for perl5 to detect those bits and emulate setuid/setgid in a secure fashion. This emulation will only work if setuid scripts have been disabled in your kernel. Do you want to do setuid/setgid emulation? [n] y
        So are there any switches I can provide to Configure or make to avoid having to use interactive setup ('make -DENABLE_SUIDPERL"TRUE" install clean' didn't work for me)
Re: Changing effecive user id
by tweetiepooh (Hermit) on Aug 27, 2009 at 10:44 UTC
    Not my area of expertise at all but can you check if mounting with nosuid? Don't know how relevant this is as I don't write SUID programmes.
      No, it's not. I guess my next question is how do I run a non-interactive install of suidperl from the 5.10.0 distribution? I don't really want to have to interactively install perl whenever I need SUID...