No such file or directory

This simple error message has causes that range from simple to sometimes pretty tricky. Most often it's that there is invisible junk on the filename, usually a newline or carriage return. Periodic reminder to include the filename in the error message to help surface such details.

    $ echo foo > bar
    $ echo bar | perl -e 'open $fh, "<", readline or die "err: $!\n"'
    err: No such file or directory
    $ echo bar|perl -e '$n=readline;open $fh,"<",$n or die "err: {$n} $!\n"'
    err: {bar
    } No such file or directory

Some languages or libraries may strip off the end-of-line character (or characters) for you, others may not. A hex viewer may be necessary if the invisible characters are difficult to see--zero-width spaces or other such Unicode funk come to mind.

getaline.c

    $ make getaline
    cc -O2 -pipe    -o getaline getaline.c
    $ echo bar | ./getaline
    getaline: fopen 'bar
    ': No such file or directory
    $ echo bar | ./getaline 2>&1 | od -bc
    0000000  147 145 164 141 154 151 156 145 072 040 146 157 160 145 156 040
               g   e   t   a   l   i   n   e   :       f   o   p   e   n
    0000020  047 142 141 162 012 047 072 040 116 157 040 163 165 143 150 040
               '   b   a   r  \n   '   :       N   o       s   u   c   h
    ...

However, process tracing may still be necessary, especially if it's something like a library search where the search doesn't bother to tell you what is going on, or where the documentation is poor, etc. On linux it got to the point where I would run strace or sysdig first, then maybe go look for documentation. Did what I just see in strace make sense with what the documentation (if any) says?

Private /tmp

Systemd may create a private /tmp directory, so the /tmp/bar for one process might be unrelated to the /tmp/bar you do not see the file in. Systemd usually has pretty good documentation, and there are good reasons to have a private temporary directory. One reason is despite /tmp vulnerabilities being well known and tools available (eventually) to create files more safely under /tmp, folks continue to write /tmp vulnerabilities. OpenBSD 2.1 came out in 1997.

    HISTORY
         The mktemp utility first appeared in OpenBSD 2.1.

Meanwhile in 2023,

In Eternal Terminal 6.2.1, TelemetryService uses fixed paths in /tmp. For example, a local attacker can create /tmp/.sentry-native-etserver with mode 0777 before the etserver process is started. The attacker can choose to read sensitive information from that file, or modify the information in that file.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-23558

So there may be merit to a private /tmp even if it does complicate things.

Security, What Ever Could That Be?

Various security frameworks have been bolted onto unix over the years; these can get in the way of expected filesystem operations. unveil(2) on OpenBSD for instance can mask a process off from a file that does exist, /etc/passwd for example.

unveil.pl

wrap.c

    $ perl unveil.pl
    err: No such file or directory
    $ make wrap
    cc -O2 -pipe    -o wrap wrap.c
    $ ./wrap
    should not happen?? No such file or directory

The security team at a small internet retailer once emptied the /etc/passwd file on a bunch of systems. That was pretty fun.

Other security frameworks can do similar. SELinux too often did a great job of preventing sshd from accessing ~/.ssh/authorized_keys on RedHat Linux, for example. Is the system secure if nobody but the hackers can login to it? Sometimes the benefits/drawbacks dial needs fiddling with, especially if there is too much friction for too little benefit.

Other

You could mount something over a file path, and probably other things I don't know about, or have forgotten about.

tags #unix