I''m running puppetd as root and I''m trying to execute tar as
the
"puppetd" user
59 define untar ( $source, $dest, $creates, $user = "puppetd" ) {
60 exec { "tar -xzf $source" :
61 cwd => $dest,
62 path => "/bin:/usr/bin",
63 user => $user,
64 creates => $creates,
65 require => [ file[$source], file[$dest] ],
66 alias => "untar-$name"
67 }
68 }
10 define sourceuntar ($file, $creates) {
11 untar { "$name-$compilerType" :
12 source => "$mathSourceDir/$file",
13 dest => $mathLibSourceDir,
14 creates => "$mathLibSourceDir/$creates" ,
15 require => file["$mathSourceDir/$file"]
16 }
17 }
62 sourceuntar { "mpich" : file => $mpiFile, creates =>
$mpiDir }
However when I run this, tar is behaving as through it''s still being
run by root and
the resulting files belong to the user as stored in the tarball, not the puppetd
user
who is supposed to be running the tar. I tried also running "id -u
>/tmp/id" in an exec and
it output 0.
Has anyone successfully used the user parameter?
Mark
--
Mark Chappell <M.D.Chappell@maths.bath.ac.uk>
Unix Systems Administrator
Mathematical Sciences, University of Bath
Mark Chappell wrote:> I''m running puppetd as root and I''m trying to execute tar as the > "puppetd" user > > 59 define untar ( $source, $dest, $creates, $user = "puppetd" ) { > 60 exec { "tar -xzf $source" : > 61 cwd => $dest, > 62 path => "/bin:/usr/bin", > 63 user => $user, > 64 creates => $creates, > 65 require => [ file[$source], file[$dest] ], > 66 alias => "untar-$name" > 67 } > 68 } > > 10 define sourceuntar ($file, $creates) { > 11 untar { "$name-$compilerType" : > 12 source => "$mathSourceDir/$file", > 13 dest => $mathLibSourceDir, > 14 creates => "$mathLibSourceDir/$creates" , > 15 require => file["$mathSourceDir/$file"] > 16 } > 17 } > > 62 sourceuntar { "mpich" : file => $mpiFile, creates => $mpiDir } > > However when I run this, tar is behaving as through it''s still being run by root and > the resulting files belong to the user as stored in the tarball, not the puppetd user > who is supposed to be running the tar. I tried also running "id -u >/tmp/id" in an exec and > it output 0. > > Has anyone successfully used the user parameter?I''ve used it, and I''ve not had these problems. I just tested it and it seems to be working, both for tar and other commands (note that puppet sets $EUID, not $UID). What platform is this? Can you do a more isolated test of just a single exec with an untar as a specified user? -- I never did give anybody hell. I just told the truth, and they thought it was hell. -- Harry S Truman --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Thu, 2006-12-07 at 10:44 -0500, Luke Kanies wrote:> Mark Chappell wrote: > > Has anyone successfully used the user parameter? > > I''ve used it, and I''ve not had these problems. I just tested it and it > seems to be working, both for tar and other commands (note that puppet > sets $EUID, not $UID). > > What platform is this? Can you do a more isolated test of just a single > exec with an untar as a specified user?Thanks for the speedy response. I noticed that it was setting the euid, and FTR it behaves as I''d expect if I change the suidmanager code so that it changes the uid instead of the euid. (Which I admit doesn''t tally with my understanding of euid and uid) This is Fedora Core 5, I''m steadily beginning to suspect that there''s something nasty going on with selinux, although it''s set to permissive. 93 class tartest { 94 exec { "tar -xzf /home/ee0mdc/libs/mpich2-1.0.4p1.tar.gz" : 95 user => puppetd, 96 path => "/bin:/usr/bin", 97 cwd => "/tmp" 98 } info: Caching configuration at /var/lib/puppet/localconfig.yaml debug: Creating default schedules notice: Starting configuration run debug: Loaded state in 0.01 seconds debug: //mapc-0079.maths.bath.ac.uk/tartest/exec=tar -xzf /home/ee0mdc/libs/mpich2-1.0.4p1.tar.gz: Changing returns debug: //mapc-0079.maths.bath.ac.uk/tartest/exec=tar -xzf /home/ee0mdc/libs/mpich2-1.0.4p1.tar.gz: 1 change(s) debug: //mapc-0079.maths.bath.ac.uk/tartest/exec=tar -xzf /home/ee0mdc/libs/mpich2-1.0.4p1.tar.gz: Executing ''tar -xzf /home/ee0mdc/libs/mpich2-1.0.4p1.tar.gz'' notice: //mapc-0079.maths.bath.ac.uk/tartest/exec=tar -xzf /home/ee0mdc/libs/mpich2-1.0.4p1.tar.gz/returns: executed successfully debug: Finishing transaction -607296128 with 1 changes debug: Storing state debug: Stored state in 0.07 seconds notice: Finished configuration run in 1.04 seconds [root@mapc-0079 tmp]# ls -lad mpich2-1.0.4p1/ drwxrwxr-x 10 619 300 4096 Aug 11 14:54 mpich2-1.0.4p1/ Mark -- Mark Chappell <M.D.Chappell@maths.bath.ac.uk> Unix Systems Administrator Mathematical Sciences, University of Bath
Mark Chappell wrote:> > Thanks for the speedy response. I noticed that it was setting the euid, > and FTR it behaves as I''d expect if I change the suidmanager code so > that it changes the uid instead of the euid. (Which I admit doesn''t > tally with my understanding of euid and uid)Hmm. It sounds like we need to switch the system from using the equivalent of backticks (ruby''s %x{}) to doing a fork, setting UID, and then running the command. I''d appreciate it if you''d file this as a bug.> This is Fedora Core 5, I''m steadily beginning to suspect that there''s > something nasty going on with selinux, although it''s set to permissive.Hmm, I''ve no experience there, so I can''t say.> 93 class tartest { > 94 exec { "tar -xzf /home/ee0mdc/libs/mpich2-1.0.4p1.tar.gz" : > 95 user => puppetd, > 96 path => "/bin:/usr/bin", > 97 cwd => "/tmp" > 98 } > > info: Caching configuration at /var/lib/puppet/localconfig.yaml > debug: Creating default schedules > notice: Starting configuration run > debug: Loaded state in 0.01 seconds > debug: //mapc-0079.maths.bath.ac.uk/tartest/exec=tar -xzf /home/ee0mdc/libs/mpich2-1.0.4p1.tar.gz: Changing returns > debug: //mapc-0079.maths.bath.ac.uk/tartest/exec=tar -xzf /home/ee0mdc/libs/mpich2-1.0.4p1.tar.gz: 1 change(s) > debug: //mapc-0079.maths.bath.ac.uk/tartest/exec=tar -xzf /home/ee0mdc/libs/mpich2-1.0.4p1.tar.gz: Executing ''tar -xzf /home/ee0mdc/libs/mpich2-1.0.4p1.tar.gz'' > notice: //mapc-0079.maths.bath.ac.uk/tartest/exec=tar -xzf /home/ee0mdc/libs/mpich2-1.0.4p1.tar.gz/returns: executed successfully > debug: Finishing transaction -607296128 with 1 changes > debug: Storing state > debug: Stored state in 0.07 seconds > notice: Finished configuration run in 1.04 seconds > > [root@mapc-0079 tmp]# ls -lad mpich2-1.0.4p1/ > drwxrwxr-x 10 619 300 4096 Aug 11 14:54 mpich2-1.0.4p1/Weird. The files in the tarball are set to UID 619? Can you verify with a stand-alone shell script that EUID is ignored when running tar? -- That was just a drill of the emergency y2k system. Had this been a real emergency, we would''ve also dumped a bucket of spiders on you and yelled out "civilization is collapsing!" --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Thu, 2006-12-07 at 14:18 -0500, Luke Kanies wrote:> Weird. The files in the tarball are set to UID 619?Yeah, that''s just an arbitrary user, not unsurprising.> Can you verify with a stand-alone shell script that EUID is ignored when > running tar?I''ve also done "id -u >/tmp/id" which came out as still thinking it''s root... Which says something even more odd... "-u : print only the effective user ID" Mark -- Mark Chappell <M.D.Chappell@maths.bath.ac.uk> Unix Systems Administrator Mathematical Sciences, University of Bath
On Thu, 2006-12-07 at 16:15 +0000, Mark Chappell wrote:> This is Fedora Core 5, I''m steadily beginning to suspect that there''s > something nasty going on with selinux, although it''s set to permissive.If it''s set to permissive, it seems unlikely that that''s the problem; have you checked /var/log/messages for any avc entries after running the tar command ? I can reproduce your problem with 0.20.1 on FC6; unfortunately, svn head is busted right now, haven''t been able to reproduce it with that. What I did is: > 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 David
On Thu, 2006-12-07 at 14:18 -0500, Luke Kanies wrote:> Mark Chappell wrote: > > > > Thanks for the speedy response. I noticed that it was setting the euid, > > and FTR it behaves as I''d expect if I change the suidmanager code so > > that it changes the uid instead of the euid. (Which I admit doesn''t > > tally with my understanding of euid and uid) > > Hmm. It sounds like we need to switch the system from using the > equivalent of backticks (ruby''s %x{}) to doing a fork, setting UID, and > then running the command. I''d appreciate it if you''d file this as a bug. > > > This is Fedora Core 5, I''m steadily beginning to suspect that there''s > > something nasty going on with selinux, although it''s set to permissive. > > Hmm, I''ve no experience there, so I can''t say.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. David
On Dec 11, 2006, at 7:35 PM, David Lutterkort wrote:> > 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.Mmm, "standard". It''s become clear that the only reasonable response is to do a full fork, change the real UID (when possible, which does not currently include all versions of Ruby on OS X), and then open the subshell. Yuck, but there isn''t much choice. popen3 here I come, either that or this: http://codeforpeople.com/lib/ruby/session/session-2.4.0/sample/ -- On Bureaucracy.... The Pythagorean theorem contains 24 words. Archimedes Principle, 67. The Ten Commandments, 179. The American Declaration of Independence, 300. And recent legislation in Europe concerning when and where to smoke, 23,942. -- The European, June 23-29, 1995 --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Dec 11, 2006, at 6:28 PM, Luke Kanies wrote:> On Dec 11, 2006, at 7:35 PM, David Lutterkort wrote: >> >> 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. > > Mmm, "standard". > > It''s become clear that the only reasonable response is to do a full > fork, change the real UID (when possible, which does not currently > include all versions of Ruby on OS X), and then open the subshell. > Yuck, but there isn''t much choice. popen3 here I come, either that > or this: > > http://codeforpeople.com/lib/ruby/session/session-2.4.0/sample/I was going to recommend this. I use it quite a bit in an older rails app. It does a great job. -Blake
On Thu, 2006-12-07 at 14:18 -0500, Luke Kanies wrote:> Hmm. It sounds like we need to switch the system from using the > equivalent of backticks (ruby''s %x{}) to doing a fork, setting UID, and > then running the command. I''d appreciate it if you''d file this as a bug.Sorry for the delay in doing this, finally opened as bug #374 Mark -- Mark Chappell <M.D.Chappell@maths.bath.ac.uk> Unix Systems Administrator Mathematical Sciences, University of Bath
Seemingly Similar Threads
- Upgrade to CentOS6.6: mpich dep error
- installing Rmpi on centos 6 with mpich
- Install Rmpi on Fedora with mpich2 installed.
- Using Xen Virtualization Environment for Development and Testing of Supercomputing and High Performance Computing (HPC) Cluster MPICH2 MPI-2 Applications
- Using Xen Virtualization Environment for Development and Testing of Supercomputing and High Performance Computing (HPC) Cluster MPICH2 MPI-2 Applications