LART of the day – the solution
Remember my LART of the day? It looked like:
% cat foo.c
int main() { return 0; }
% gcc foo.c
foo.c:1: fatal error: can’t open /tmp/ccxgyEhb.s for writing: Permission denied
compilation terminated.
Congratulations to sunckell and Bernd for guessing the right answer.
Additionally to the blog comments (which I delayed through moderation to give everyone the same chance) I received further comments through ICQ/Jabber/IRC. It’s interesting that most people think it’s related to /tmp, but the issue isn’t related to /tmp at all.
The solution
Umask settings.
Just try my demo with ‘umask 222’. No mount/ACL/SELINUX/whatsoever tricks necessary. :) To clarify:
% umask 002 % gcc foo.c % umask 222 % gcc foo.c foo.c:1: fatal error: can’t open /tmp/ccteC66I.s for writing: Permission denied compilation terminated. % touch /tmp/ccteC66I.s % ls -la /tmp/ccteC66I.s -r--r--r-- 1 mika mika 0 Oct 31 12:56 /tmp/ccteC66I.s
I stumbled upon this LART by accident. As part of implementing a specialized configuration management system for a customer I had to deal with permission handling. The requirement was to generate configuration files based on the permissions of the template files but remove any existing write permissions. While playing with umask settings I noticed that you can’t set umask in the shell to get the executable flag being set. I was aware of umask(2) and always had its 0777 in mind. But files are actually generated via:
0666 & ~umask
by default instead. As I noticed that most people aren’t aware of this fact and that a umask of 222 turns out to be pretty unobtrusive this was the perfect base for a LART. Learning something new and coming up with a LART at the same time. Win-win! :)