I'm working on an assignment on adding time support to a standard UNIX system. Part of it, however, involves securing the location of backup files (which we've set to be at the system root by default) by making them invisible, even through a command like "ls -al" and can only be accessed by specifying its absolute path name. Here's the original quote:

Finally, historical directories should be "virtual", in the sense that they do not appear when examining the contents of the inode representing the root directory or when performing a command like "ls -al /", and are only accessible through a direct chdir() ("cd") operation to a historical pathname.

I've been prowling through the UNIX file system API but I haven't come up with a way to enforce this (I'm thinking a command line program or a combination of these in a bash script might do the job). Am I thinking in the wrong direction?

Would appreciate any pointers or tips in the right direction, thanks :)

  • Newer seen anything like that..
    – vonbrand
    Apr 16, 2014 at 15:48
  • Maybe something like mkdir " "?
    – devnull
    Apr 16, 2014 at 15:59
  • @devnull and adding some control character in it (so it would mess with ls display) ? ... remind me of some junior years pranks
    – Ouki
    Apr 16, 2014 at 16:10
  • @Ouki The control characters might still show up in some form upon doing ls -l. This wouldn't.
    – devnull
    Apr 16, 2014 at 16:15
  • 1
    This is what rootkits do...
    – user41515
    Apr 16, 2014 at 19:45

2 Answers 2


You can remove read permission from a directory. In that case it is still possible to access its content (files or subdirectories, given that their permissions allow it) but you must know (or: try...) their name as listing of the directory content is not possible any more.

  • I actually thought about that - but can't another user simply change the permissions of the directory again with chmod? I want to assume that not even the super user of the system can change the permission subsequently from making further changes
    – blazonix
    Apr 16, 2014 at 16:10
  • 1
    @blazonix In general: Fighting against the superuser is useless (at least in most environments). The file / directory permissions can be changed by the owner only (plus those privileged by RichACLs if they are in use) - and by the superuser (or those processes having CAP_FOWNER). The only way of preventing the superuser from doing that which I am aware of is FUSE. In that case the cooperation of a program is required which is not controlled by the superuser. At least not directly. Of course, root can hack FUSE permissions (with a little more effort), too. Apr 16, 2014 at 16:23
  • I see what you mean...but I suppose this backup feature would do fine even without imposing such a strict restriction preventing the super user from doing system calls. An extra thought - do you think it's a good design choice for the UNIX system to have a super user?
    – blazonix
    Apr 19, 2014 at 13:10
  • @blazonix: Without a super-user the OS would still need a way to grant unusual permissions. And as Linux found out with capabilities, most of these unusual permissions can be abused to grant all the others. If you can load modules into the kernel you can write kernel code. If you can change file permissions you can overwrite ls with an evil version. If you can make backups you can read private files and try to crack the system password hashes.
    – Zan Lynx
    Sep 19, 2014 at 21:56
  • @HaukeLaging I suppose that's true - I think the question then becomes how to protect the superuser's status in the operating environment from an operations perspective - it's disastrous to eve imagine the kernel code can just be accessed and modified
    – blazonix
    Sep 20, 2014 at 3:24

You can prevent non-root users from listing the content of a directory while allowing them to access files in that directory by giving them the x permission but not r. For a directory, r (“read”) means that you can list the content, whereas x means that you can access files in the directory or cd into it. However, this doesn't seem to be what the assignment means since it isn't refering to permissions.

With normal filesystems, the entries in a directory are the ones that appear in the directory list. However, if you control the filesystem driver, then you can violate this convention. Here are a few examples that you might find in the wild:

  • In a case-insensitive filesystem, in a directory whose listing shows just one file Foo, you can also access files called FOO, fOO, etc. They're all the same file because the filesystem driver is designed this way.
  • Some automounters react to a directory name and attempt a mount accordingly. For example, an automounter configured for NFS typically decides that when you access /amnt/myserver/somedir, it attempts to mount myserver:/somedir, which brings the directories /amnt/myserver and /amnt/myserver/somedir into existence.
  • In AVFS, if a file is recognized as an archive, then you can access it as a directory, but the fake directory name doesn't appear in the directory listing: if ls ~/.avfs/path/to shows a foo.zip then a directory ~/.avfs/path/to/foo.zip# also exists.
  • Some filesystem snapshot systems operate in the way described by your assignment: if you access a directory /snapshot/20140415022342 or /snapshot/yesterday then you get the latest snapshot before the specified time.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .