In the pbs_postinstall script I see two lines containing this:
rm -f /etc/rc.d/rc?.d/*pbs
but, if called via sudo, results in unexpanded wildcards in filename, as if called this way:
rm '-f /etc/rc.d/rc?.d/*pbs'
<p>To address comment, I tried running INSTALL under sudo as follows on vcc@testdev-02-s11p2:~/PBSPro_13.0.2> <br />
sudo PATH=/opt/tools/wrappers:$PATH ./INSTALL and I was unable to reproduce this issue and INSTALL worked fine.</p>
I also tried to run:<br> rm -f /etc/rc.d/rc?.d/*pbs<br><br>under sudo with /opt/tools/wrappers in the start of PATH and did not see the problem:<br><br>vcc@testdev-02-s11p2:> ls -l /etc/rc.d/rc?.d/*pbs <br>lrwxrwxrwx 1 root root 6 Oct 29 21:32 /etc/rc.d/rc3.d/K01pbs -> ../pbs<br>lrwxrwxrwx 1 root root 6 Oct 29 21:32 /etc/rc.d/rc3.d/S08pbs -> ../pbs<br>lrwxrwxrwx 1 root root 6 Oct 29 21:32 /etc/rc.d/rc5.d/K01pbs -> ../pbs<br>lrwxrwxrwx 1 root root 6 Oct 29 21:32 /etc/rc.d/rc5.d/S08pbs -> ../pbs<br><br>vcc@testdev-02-s11p2:> PATH=/opt/tools/wrappers:$PATH rm -f /etc/rc.d/rc?.d/*pbs<br>/bin/rm: cannot remove `/etc/rc.d/rc3.d/K01pbs': Permission denied<br>/bin/rm: cannot remove `/etc/rc.d/rc3.d/S08pbs': Permission denied<br>/bin/rm: cannot remove `/etc/rc.d/rc5.d/K01pbs': Permission denied<br>/bin/rm: cannot remove `/etc/rc.d/rc5.d/S08pbs': Permission denied<br><br>vcc@testdev-02-s11p2:> sudo PATH=/opt/tools/wrappers:$PATH rm -f /etc/rc.d/rc?.d/*pbs<br> <br>vcc@testdev-02-s11p2:> ls -l /etc/rc.d/rc?.d/*pbs <br>ls: cannot access /etc/rc.d/rc?.d/*pbs: No such file or directory<br>[Security:Internal]
<p>The wrappers are getting passed what is essentially garbage. The installer should not do this.<br />
With few exceptions, e.g. find's -name option which takes escaped wildcards and uses glob itself<br />
when ftw executed, the shell almost always does any wildcard expansion – it's not up to the called program to<br />
do this. So, I think the vast majority of prior art indicates the wrappers are behaving in the<br />
least surprising ( i.e. the correct ) way.</p>
<p>At present, the wrappers have a rule that silently ignores this condition, but in the case of<br />
something like rm, this means that some files may be left behind which should not be.</p>
<p>Could you explain why this is a bug with PBS post install vs. the wrappers?</p>
<p>More from Harry's email:<br><br><font size='2'><span style='font-size:10pt;'>As to what's wrong, that's simple. The shell script is passing unexpanded wildcards to the<br />
<br />
wrapped functions. E.g. instead of <br />
<br />
rm file1 file2 file3</p>
<p>the wrapped rm is seeing <br />
<br />
rm file*<br><br />
<br />
It's the shell's job to expand the list before calling the wrapper. <br />
<br />
I found a case that I thought would explain it. This involved the euid not being able to<br />
read the directory contents. However, the installer runs as root, so although it's<br />
an interesting case, it isn't really relevant. I don't know why the installer is doing<br />
what it does, but I do think I've shown that it's wrong in my previous email<br />
since these scripts often use the -f flag with rm, in the past it was just<br />
failing silently anyway since a file with a wildcard in the name didn't exist.<br />
What the wrappers have revealed is that whatever the author of the script had intended to<br />
happen, probably isn't.</p>