Re: Changing effecive user id

[Crackers2]

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

[astroboy]

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

[astroboy]

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)