New to tumbleweed, but not new to linux or opensuse. I upgraded to Tumbleweed last night from an older openSuse install. Had a few problems getting there, but worked through those. Now I’m cleaning up and fixing the things that changed or broke.
One unexpected failure is that ps2pdf (/usr/bin/ps2pdf) no longer works. It’s a pretty simple shell script, and I don’t understand the failure here.
#!/bin/sh
# Convert PostScript to PDF.
# Currently, we produce PDF 1.4 by default, but this is not guaranteed
# not to change in the future.
version=14
ps2pdf="`dirname \"$0\"`/ps2pdf$version"
if test ! -x "$ps2pdf"; then
ps2pdf="ps2pdf$version"
fi
exec "$ps2pdf" "$@"
Running it produces the output:
dgersic@farfalla:~> /usr/bin/ps2pdf
/usr/bin/ps2pdf: line 8: /usr/bin/dirname: Permission denied
/usr/bin/ps2pdf: /usr/bin/ps2pdf14: /bin/sh: bad interpreter: Permission denied
/usr/bin/ps2pdf: line 12: /usr/bin/ps2pdf14: Success
I don’t see anything wrong with line 8 there. And /bin/sh is perfectly fine. It appears that the only purpose to this script is to set a default output version (14), it then calls a similar script (ps2pdf14) from the same directory.
If I run it with -x I get:
dgersic@farfalla:~> sh -x ps2pdf
+ version=14
++ dirname ps2pdf
+ ps2pdf=./ps2pdf14
+ test '!' -x ./ps2pdf14
+ ps2pdf=ps2pdf14
+ exec ps2pdf14
/usr/bin/ps2pdf14: line 3: /usr/bin/dirname: Permission denied
/usr/bin/ps2pdf14: /usr/bin/ps2pdfwr: /bin/sh: bad interpreter: Permission denied
/usr/bin/ps2pdf14: line 7: /usr/bin/ps2pdfwr: Success
Similarly, ps2pdf14 is a wrapper for ps2pdfwr. And ps2pdfwr does the same thing. If I run it from the shell, it complains about /usr/bin/dirname and /usr/bin/basename, but if I run it with /bin/sh -x it seems to work correctly.
I’ve been staring at this and don’t see it. What am I missing here?
While I am as amazed as you are. I note that when you show the sh -x case, you do not call /usr/bin/ps2pdf (as you use the full path in your first case), but ps2pdf. The result of dirname is then . (current working directory), thus I assume that your working directory is /usr/bin in that case.
As the obvious error message comes from ps2pdfwr, I guess we can assume that the wrappers work correct and dirname gves no errors here.
You do not tell what the “older openSuse install” was (I guess something with openSUSE), nor how you upgraded. When you thought it is worth while to mention that you just upgraded (and it is), better tell it all. Else we have only a vague idea that around the corner there might be something …
I had no doubt about that, but when compairing two tests, one should of course keep the differences to a minimum. Were it only because the interpreters will try to explain every character that is different. My goal was at least partly to help others understanding what they see.
Again, that is as expected, but it triggered me, specialy because a “normal” user does not often use a system directory as his/her working directory.
Also the default bash prompt shows to working directory, which your prompt doesn’t. Again something to pay attention to when interpreting your CODE snippets.
The upgrade was from opensuse 11.4. I don’t know if that’s relevant detail. Upgraded from the Tumbleweed DVD downloaded the night before. The problems I ran in to during the upgrade were with the on-line repos. I was getting sporadic 404 errors when it was trying to fetch upgraded versions. I went with just what was on the DVD and the upgrade progressed fine.
But about your “upgrade”. Was that a new install or did you try to use the Upgrade item of the main installer menu?
In the last case, I doubt very much that such an upgrade is supported (or ever tested in QA). Artifacts of the older installation might create havoc. Difficult to find if that is the case here.
Let us ask other TW users to test this. Easy enough, just do
So it’s not the script itself. I moved the new copy to /usr/bin and it fails over there. So it’s something with my / file system or something that’s preventing it from running.
Found it - there’s a new profile that covers various postscript-related binaries.
Please run
aa-complain /etc/apparmor.d/usr.bin.gs
to set the profile into complain/learning mode.This means:
ps2pdf will work again
/var/log/audit/audit.log will be filled with things that would be denied, and can then be used for a bugreport and for updating the profile (for the records: you’ll get ALLOWED instead of DENIED log entries)
That said: Please open a bugreport and attach your /var/log/audit/audit.log after running ps2pdf with the profile in complain mode.
I just found this thread after running into a problem importing an EPS file into Inkscape. Thanks for the solution! Will AppArmor go back to enforcing this profile normally when they fix it, or will I have to run a new command in order to go back to normal enforcement?
