14

I need this for a unit test. There's a function that does lstat on the file path passed as its parameter. I have to trigger the code path where the lstat fails (because the code coverage has to reach 90%)

The test can run only under a single user, therefore I was wondering if there's a file in Ubuntu that always exists, but normal users have no read access to it, or to its folder. (So lstat would fail on it unless executed as root.)

A non-existent file is not a solution, because there's a separate code path for that, which I'm already triggering.

EDIT: Lack of read access to the file only is not enough. With that lstat can still be executed. I was able to trigger it (on my local machine, where I have root access), by creating a folder in /root, and a file in it. And setting permission 700 on the folder. So I'm searching for a file that is in a folder that is only accessible by root.

  • 6
    IMHO /etc/shadow – Romeo Ninov Feb 25 '19 at 11:52
  • 3
    You cannot assume the existence of any file, because your program may run in a chroot or separate namespace. If assuming that /proc is mounted is OK and init is nothing special, then /proc/1/fd/0 should do. – mosvy Feb 25 '19 at 12:12
  • 1
    @mosvy Thanks that works on my local machine. Hmm then I'll try it on the QA and Staging pool too. – Crouching Kitten Feb 25 '19 at 12:15
  • 2
    Why are you tying your test code to a particular flavor of OS when you could just create a throwaway file and remove your own read access to it? – Kilian Foth Feb 25 '19 at 16:05
  • 4
    I'd argue that it's not really a unit test once it starts depending on a real, rather than mocked, filesystem. – Toby Speight Feb 25 '19 at 17:05
21

On modern Linux systems, you should be able to use /proc/1/fdinfo/0 (information for the file descriptor 1 (stdout) of the process of id 1 (init in the root pid namespace which should be running as root)).

You can find a list with (as a normal user):

sudo find /etc /dev /sys /proc -type f -print0 |
  perl -l -0ne 'print unless lstat'

(remove -type f if you don't want to restrict to regular files).

/var/cache/ldconfig/aux-cache is another potential candidate if you only need to consider Ubuntu systems. It should work on most GNU systems as /var/cache/ldconfig is created read+write+searchable to root only by the ldconfig command that comes with the GNU libc.

  • 1
    Thanks! If /proc/1/fdinfo/0 works on Ubuntu 16.04 and 18.04, that's more than enough. – Crouching Kitten Feb 25 '19 at 12:17
  • 1
    Using /proc/1/fdinfo/0 does not necessarily work in a container (e.g., a Docker container), and often unit tests are run in such containers in CI. – Philipp Wendler Feb 26 '19 at 9:05
  • @PhilippWendler, I did mention the root pid namespace already. The OP is not asking about containers but about files guaranteed to be there in the filesystem layout of a Ubuntu system. As containers could contain any file and directory layout, that question could not be answerable there. – Stéphane Chazelas Feb 26 '19 at 9:39
12

Looking at the lstat(2) man page you can get some inspiration on cases that might make it fail with errors other than ENOENT (file does not exist.)

The most obvious one is:

EACCES Search permission is denied for one of the directories in the path prefix of path.

So you need a directory you can't search from.

Yes, you can look for one that's already in your system (perhaps /var/lib/private if it exists?) But you might as well create one yourself, with the equivalent of:

$ mkdir myprivatedir
$ touch myprivatedir/myunreachablefile
$ chmod 0 myprivatedir
$ ls -l myprivatedir/myunreachablefile

The lstat(2) operation will fail with EACCES here. (Removing all permissions from the directory ensures that. Maybe you don't even need that much and chmod -x removing execute permissions would be enough, since execute permissions on a directory are needed to access files under it.)

There's another creative way to make lstat(2) fail, looking at its man page:

ENOTDIR A component of the path prefix of path is not a directory.

So, trying to access a file such as /etc/passwd/nonexistent should trigger this error, which again is different from ENOENT ("No such file or directory") and might suit your needs.

Another one is:

ENAMETOOLONG path is too long.

But you might need a really long name for this one (I believe 4,096 bytes is the typical limit, but your system/filesystem might have a longer one.)

Finally, it's hard to tell whether any of these will be actually useful for you. You say you want something that doesn't trigger the "file doesn't exist" scenario. While typically that means an ENOENT error, in practice many higher-level checks will simply interpret any errors from lstat(2) as "does not exist". For example test -e or the equivalent [ -e ...] from the shell might simply just interpret all of the above as "does not exist", especially since it doesn't have a good way to return a different error message and not returning an error would imply the file exists, which is most certainly not the case.

  • @StephaneChazelas Great point! Updated. – filbranden Feb 25 '19 at 15:22
6

You can find it yourself.

Using /etc -- the configuration files directory as a starting point:

sudo find /etc -type f -perm 0400 -user root

On my system, this does not return anything.

You can be a less restrictive and allow group root (only user root should be a member of group root), and a look out for a permission of 440:

sudo find /etc -perm 0440 -user root -group root

On my system this returns:

/etc/sudoers.d/README
/etc/sudoers

Edit:

Based on your edit, you're looking for a directory that does not have sufficient permission for the invoking user to prevent directory listing:

sudo find / -perm o-rwx -type d -user root -group root 

here I'm looking for directories (-type d) that lack the read-write-execute perm bits for others (o-rwx) and is owned by root:root.

Technically, just the absense of execute (x) bit would prevent a directory listing (lstat(2)) on directory.

In the output I've found /run/systemd/inaccessible/ on my Systemd init based system.

Regarding files in /proc, /sys, /dev:

  • These filesystems are virtual FS i.e. they reside on memory, not on disk

  • If you plan to rely on /proc, use /proc/1/ i.e. rely on something under PID 1, not any later PIDs to have reliability/consistency as the later PIDs (processes) are not guaranteed to exist.

  • Thanks, I think my question is wrong. I can still lstat files without read access to them. Maybe the access to the folder has to be limited? (I modified the title) – Crouching Kitten Feb 25 '19 at 11:59
  • Thanks. With find / -type d -perm 0400 -user root I have found the directory /proc/20/map_files/, if I refer to a made-up file name inside that folder, like /proc/20/map_files/asdasd, then it always fails. Does that folder always exist on Ubuntu? – Crouching Kitten Feb 25 '19 at 12:12
  • @CrouchingKitten, the directories in /proc/1/ might be safer, since init always exists. But that's proc, not a regular filesystem, in case it matters. – ilkkachu Feb 25 '19 at 12:17
  • Thanks I gave an upvote, but accepted the other answer, because he said it is guaranteed that /proc/1/fdinfo/0 works on modern Ubuntus. – Crouching Kitten Feb 25 '19 at 12:21
  • -perm o-rwx is like -perm 0, bits are all off to start with. Here, you'd want ! -perm -1. – Stéphane Chazelas Feb 25 '19 at 13:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.