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


in reply to Changing effecive user id

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

Replies are listed 'Best First'.
Re^2: Changing effecive user id
by astroboy (Chaplain) on Aug 27, 2009 at 04:51 UTC

    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)