Don't understand german? Read or subscribe to my english-only feed.

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?

9 Responses to “LART of the day – guess what’s wrong”

  1. joschi Says:

    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.

  2. Konstantin Khomoutov Says:

    SELinux or some other MAC kicks in?

  3. sunckell Says:

    Watcha got /tmp mounted with?

  4. sunckell Says:

    Ah Man.

    What’s your umask?
    umask 755 -> creates that issue…

    Not the mount…

  5. Woody Says:

    The command which /usr/bin/gcc is only showing that there is a command called gcc in the /usr/bin directory

    I assume there is a rogue gcc earlier in the path.

    This can be verified by running:

    which gcc

    Thanks

  6. Bernd Says:

    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? ;)

  7. mueli Says:

    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

  8. Thomas Says:

    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…

  9. mika Says:

    @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-