"setuid(UID)" and "chmod 4550" misbehaving

[Will Trillich <will@serensoft.com>]

TASK:     allow USER1 to run a program AS USER2.
SOLUTION: setuid bit (in theory, right?)
PROBLEM:  theory not matching execution...

we've got a little C program that must be RUN AS a certain user
(cyrus) BY another user (www-data) so we figured turning on the
SETUID bit would work:

    # cd /usr/share/squirrelmail/plugins/chg_sasl_passwd
    # gcc -o chgsaslpasswd chgsaslpasswd.c
    # chown cyrus.www-data chgsaslpasswd
    # chmod 4550 chgsaslpasswd

now, to double-check:

    # ls -F chgsaslpasswd
    -r-sr-x---  1 cyrus  www-data  12346 Jun 17 18:51 chgsaslpasswd*

so, any user in group www-data should be able to execute this and
thereby BECOME user cyrus for the duration of the run, right?

    # groups www-data
    www-data : www-data

so it's definitely runnable by apache (being user www-data),
which should execute this SUID as cyrus. right? let's make sure
the program does what we're expecting, as user cyrus:

    # su cyrus
    $ ./chgsaslpasswd -p cyrus
    __ ./chgsaslpasswd: setuid(103): YAY!newPasswordHere
    $ exit

works like a dream; the password has been changed (which we
confirm by trying cyradm for user cyrus). at any rate, we now
try the same thing as user www-data:

    # su www-data
    $ ./chgsaslpasswd -p cyrus
    __ ./chgsaslpasswd: setuid(103): YAY!tryAnotherPassword
    chgsaslpasswd: generic failure
    $ exit

generic failure?

this doesn't even work when run as root! is there something we're
missing in the SUID bit? why doesn't this SUID to cyrus?

we also checked the SUID properties specified for MOUNT, in case
the partition spec was interfering:

    # mount
    /dev/sda1 on / type ext3 (rw)
    proc on /proc type proc (rw)
    devpts on /dev/pts type devpts (rw,gid=5,mode=620)
    tmpfs on /dev/shm type tmpfs (rw)
    /dev/sda2 on /tmp type ext3 (rw)
    /dev/sda8 on /usr type ext3 (rw)
    /dev/sda6 on /var type ext3 (rw)
    /dev/sda5 on /var/log type ext3 (rw)
    /dev/sda7 on /home type ext3 (rw)
    usbfs on /proc/bus/usb type usbfs (rw)

    # cat /etc/fstab
    /dev/sda1        /       ext3    defaults        0       1
    /dev/sda3        none    swap    sw              0       0
    /dev/sda2        /tmp    ext3    defaults        0       1
    /dev/sda8        /usr    ext3    defaults        0       1
    /dev/sda6        /var    ext3    defaults        0       1
    /dev/sda5        /var/log ext3   defaults        0       1
    /dev/sda7        /home   ext3    defaults        0       1
    proc       /proc         proc    defaults        0       0
    /dev/fd0   /mnt/auto/floppy auto defaults,user,noauto,showexec,umask=022  0  0
    /dev/cdrom /mnt/auto/cdrom  auto defaults,ro,user,noexec,noauto 0  0

didn't find any "nosuid" anywhere. aaugh!


so, then, what's interfering with the SUID bit? (we're betting on
"lack of knowledge"...)


here's the itty-bitty C program--

  LISTING>>>>>>>>>>>>>>>>>>>>>>>>>>>>

  #include <stdio.h>
  #include <unistd.h>

  // set the UID this script will run as (cyrus user)
  #define UID 103
  // set the path to saslpasswd2
  #define CMD "/usr/sbin/saslpasswd2"

  main(int argc, char *argv[])
  {
    int rc,suid;

    // is this "setuid" even useful? for non-root users?
    if ( 0 == (suid = setuid(UID)) ) {

      // WE GET HERE
      fprintf(stderr,"__ %s: setuid(%d): YAY!",argv[0],UID);

      // do the deed:
      if ( 0 == (rc = execvp(CMD, argv)) ) {
        // only works for user cyrus -- no setuid taking place!
        // NEVER GETS HERE (execvp replaces current process)
        //fprintf(stderr,"__ %s: execvp(%s...): YAY!",argv[0],CMD);
      } else {
        // NEVER GETS HERE
        fprintf(stderr,"__ %s: can't execvp(%s...): error %d",argv[0],CMD,rc);
      }

    } else {
      // NEVER GETS HERE EITHER
      fprintf(stderr,"__ %s: can't setuid(%d): error %d",argv[0],UID,suid);
    }

  }

  <<<<<<<<<<<<<<<<<<<<<<<<<<<<LISTING



or, better yet, is there a debian-savvy "squirrelmail-plugins"
install method?

-- 
I use Debian/GNU Linux version 3.0;
Linux boss 2.4.18-bf2.4 #1 Son Apr 14 09:53:28 CEST 2002 i586 unknown
 
DEBIAN NEWBIE TIP #104 from Sean Quinlan <smq@gmx.co.uk>
:
Looking to CUSTOMIZE THE COLORS USED BY LS?  I find it's easier
to run "dircolors -p >~/.dircolors" and then add "eval
`dircolors -b ~/.dircolors`" to my .bashrc and then make all
changes to ~/.dircolors (instead of the system-wide
/etc/DIR_COLORS).  Probably more pertinent on a multi user
system, but good policy nevertheless.

Also see http://newbieDoc.sourceForge.net/ ...