Puppet

Should have opened the ticket sooner, sorry. Summary from puppet-user:

Under Fedora,

   > cat /tmp/t.pp
    exec { uid-test:
      command => "/usr/bin/id > /tmp/id.txt",
      user => lutter
    }

    > puppet -v /tmp/t.pp 
    notice: //exec=/usr/bin/id > /tmp/id.txt/returns: executed successfully
    info: Creating state file /var/lib/puppet/state/state.yaml

    > cat /tmp/id.txt 
    uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=user_u:system_r:unconfined_t

    > ls -l /tmp/id.txt 
    -rw-r--r-- 1 root root 125 Dec  8 10:10 /tmp/id.txt

This shows that the euid was dropped by the shell in favour of the uid… David Lutterkort has found the following, probable cause.

After a little bit of digging, here’s what’s going on: after puppet sets the euid/egid, it does a %x{CMD}, which execs ‘/bin/sh -c CMD’; according to bash(1)

    If the shell is started with the effective user (group) id not
    equal to the real user (group) id, and the -p option is not
    supplied, no startup files are read, shell functions are not
    inherited from the environment, the SHELLOPTS variable, if it
    appears in the environment, is ignored, and the effective user
    id is set to the real user id.

What surprises me is that this doesn’t happen on other platforms … I would have assumed that bash emulates sh there and that that behavior is pretty much standard.