SDP-63
Closed
p4master_run operates incorrectly as root.
Hey Tom, I was rebuilding my test server today and I ran into an issue
with the SDP scripts. I’m using the released version from April 8th, and
I discovered if you run p4master_run as root, it fails with a usage message.
After some investigating I was able to find the problem, and I was wondering
if I should offer up a fix on the main branch or the dev branch?
The problem is you grab the instance from $1 then do a shift. Later in the
script, you test if the person running the script is UID 0, and if so, it does:
exec su - $OSUSER –c "$0 $@"
This results in the usage message from p4master_run, and your intended command
doesn't get run. The reason is '$@' no longer contains the instance that was
the first argument, because it got shifted out. I hit this because the crontab
file has the following line at the end:
*/5 * * * * [ -e /p4/common/bin ] && /p4/common/bin/p4master_run ${INSTANCE} /p4/common/bin/p4review.py ${INSTANCE}
If you run p4master_run with "bash –x" you'll see it happen:
+ exec su - p4admin -c '/p4/common/bin/p4master_run /p4/common/bin/p4review.py' 1
It would be even worse if you used the '-c' argument, there's a block that
checks for '-c', makes sure there is something after it, sets a variable CRON
(which is never used), and does another shift, removing the '-c' from $@.
I also noticed all the shell scripts in the crontab file no longer use p4master_run,
and source p4_vars themselves, however, the comment block at the top still says you
need run call the script from p4master_run.
Hey Tom, I was rebuilding my test server today and I ran into an issue
with the SDP scripts. I’m using the released version from April 8th, and
I discovered if you run p4master_run as root, it fails with a usage message.
After some investigating I was able to find the problem, and I was wondering
if I should offer up a fix on the main branch or the dev branch?
The problem is you grab the instance from $1 then do a shift. Later in the
script, you test if the person running the script is UID 0, and if so, it does:
exec su - $OSUSER –c "$0 $@"
This results in the usage message from p4master_run, and your intended command
doesn't get run. The reason is '$@' no longer contains the instance that was
the first argument, because it got shifted out. I hit this because the crontab
file has the following line at the end:
*/5 * * * * [ -e /p4/common/bin ] && /p4/common/bin/p4master_run ${INSTANCE} /p4/common/bin/p4review.py ${INSTANCE}
If you run p4master_run with "bash –x" you'll see it happen:
+ exec su - p4admin -c '/p4/common/bin/p4master_run /p4/common/bin/p4review.py' 1
It would be even worse if you used the '-c' argument, there's a block that
checks for '-c', makes sure there is something after it, sets a variable CRON
(which is never used), and does another shift, removing the '-c' from $@.
I also noticed all the shell scripts in the crontab file no longer use p4master_run,
and source p4_vars themselves, however, the comment block at the top still says you
need run call the script from p4master_run.
- Status
- Closed
- Project
- perforce-software-sdp
- Severity
- C
- Reported By
- UnstoppableDrew
- Reported Date
- Modified By
- super-tom_tyler
- Modified Date
- Owned By
- UnstoppableDrew
- Dev Notes
- This job, SDP-63, was originally named job000543.
- Type
- Bug