LART of the day – guess what’s wrong
Update: see LART of the day – the solution for the solution.
% 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.
Uh?! Ok, does the file exist? Do I have write permissions? gcc ok?
% pwd /tmp % ls -lad /tmp drwxrwxrwt 23 root root 1000 Oct 29 16:43 /tmp/ % ls -la /tmp/ccxgyEhb.s ls: cannot access /tmp/ccxgyEhb.s: No such file or directory % echo foo > /tmp/ccxgyEhb.s % cat /tmp/ccxgyEhb.s foo % which gcc /usr/bin/gcc % gcc --version | head -1 gcc (Debian 4.4.3-7) 4.4.3
Alright, everything looks fine, right?
Assuming I would apply this LART to YOU, would you correctly guess what I did to you?
October 29th, 2010 at 18:46
You could’ve created some SELinux/AppArmor/Tomoyo/RSBAC/grsecurity rules for /usr/bin/gcc so it’s not able to write into /tmp any more.
October 29th, 2010 at 18:52
SELinux or some other MAC kicks in?
October 29th, 2010 at 19:04
Watcha got /tmp mounted with?
October 29th, 2010 at 19:30
Ah Man.
What’s your umask?
umask 755 -> creates that issue…
Not the mount…
October 29th, 2010 at 21:11
The command
which /usr/bin/gcc
is only showing that there is a command calledgcc
in the/usr/bin
directoryI assume there is a rogue
gcc
earlier in the path.This can be verified by running:
which gcc
Thanks
October 29th, 2010 at 21:50
I get pretty much the same thing (mutatis mutandis – it’s a Mac with older gcc) here: I’d guess the umask is something like, 3 for owner? ;)
October 29th, 2010 at 22:34
Hi!
Nice riddle. :-) Just to clarify – ‘/tmp’ has enough space to hold more then the 4 bytes of your test cat file? I am asking without trying to reproduce this full ‘/tmp’ issue and I also hope that gcc would respond with a more appropriate “out of space” message.
g, Michael
October 30th, 2010 at 11:55
Your “which” command tells everything: You hide the output of “which gcc”, which seems to be an alias or a shell function doing bad stuff before calling the “real” gcc…
October 31st, 2010 at 14:17
@joschi: nice approach, but no :)
@Konstantin: nope
@sunckell: irrelevant, as it works for the echo command in the shell
@sunckell: excellent catch, congratulations!
@Woody: sorry, my fault – it’s the correct output but I fscked up with c/p, should have been ‘which gcc’ of course.
@Bernd: excellent guess, congrats! :)
@mueli: everything fine and executing gcc would fail on ENOSPC with “/usr/bin/ld: final link failed: No space left on device”
@Michael: no, was a c/p error – should have been ‘which gcc’ and everything OK with gcc, good catch though but sadly my fault – sorry for the confusion :)
regards,
-mika-