in reply to Setuid script not working

Why did you omit any error checking? perlvar clearly states: Since changes to $< require a system call, check $! after a change attempt to detect any possible errors, similar statements exist for $>, $(, and $).

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Replies are listed 'Best First'.
Re^2: Setuid script not working
by druidmatrix (Acolyte) on Apr 30, 2010 at 06:06 UTC

    Thank you for your response. I looked for $! and sure enough it is populated, but does not explain why it failed. 

    $< = $> = 0;
        print "Could not setuid ".$<." error: $! \n" if ($<);
        POSIX::setuid(0) if ($<);
        print "Posix could not setuid either ".$<." error: $! \n" if (
+$<);

    [download]
    It now produces: 
    Could not setuid 500 error: Operation not permitted
Posix could not setuid either 500 error: Operation not permitted

    [download]
[reply]
[d/l]
[select]
      but does not explain why it failed.

      Yes it does, Operation not permitted. Oh you want to know why it isn't permitted? You'll have to rule out each possibility (or use strace, OS usually doesn't provide backtrace)

[reply]

        Linux, like many other Unix variants, ignores the setuid-bit on scripts. So your script runs as unprivileged user. Unprivileged users aren't allowed to change the UID or GID, hence the "Operation not permitted" error.

        Perl once had a separate interpreter, suidperl, that was installed setuid root, and that should respect the setuid-bit on scripts. It never worked as secure as it should, so it was deprecated and finally removed.

        Consider using sudo, as recommended in perl587delta. Read perlsec for a different approach. A third approach may be splitting the job into a privileged daemon and an unprivileged front-end, communicating over unix domain sockets or named pipes.

        Alexander

        --
        Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
[reply]

        strace will give you the same message 

        setuid32(0) = -1 EPERM (Operation not permitted)

        [download]

        Not that helpful, except it tells you which system call's man page you should be reading. 

        $ man setuid32
...
       EPERM  The user is not privileged (Linux: does
              not have the CAP_SETUID capability) and
              uid does not match the real UID or saved
              set-user-ID of the calling process.
...

        [download]
[reply]
[d/l]
[select]
        Thank you for the suggestions. I believe the root cause has been exposed in the thread above; however, if it is not too much, I would be interested in a simple example of using backtrace/strace to investigate an issue like this.
[reply]

        Once again, thank you for your response regarding the setuid module/part that is required to run setuid programs. I believe it is still possible to configure this with the current installer, however, I am having some issues with doing so silently (please see my response in the thread above).

        Also, very grateful for the lil' strace tutorial above! :)

[reply]

In Section Seekers of Perl Wisdom