A user (call him user01) on a shared file system has attempted to set up files to only be read by him. I can enter the directory, and an ls -l produces output like :

ls -l

-rwx------ 1 user01 gp 16035 Dec 21  2015 Output.cpp

Clearly I don't have read permissions for this file, yet I am able to copy/read it! (I won't post the output here, but I can emacs/cat/cp the file and view the contents without issue) For reference, I am not even a member of the group same group (gp), and I should have no special sudo permissions on this file system.

How is this possible?

  • 2
    You haven't demonstrated you can read the file, just that you can see the name. That consistents of reading the directory and doesn't touch the file at all. Reading directory contents depends on the permissions of the directory and not the file. – Stephen Harris Sep 16 '16 at 16:57
  • Don't use different users on here. I accepted your edit but further operations should be done with the funky_donkey user. – Julie Pelletier Sep 16 '16 at 17:04
  • 1
    What you're saying is not credible as that is not the way the system works unless you do have privileges that you don't realize. You should at least show us your output of id and specify the filesystem used where that file is located. – Julie Pelletier Sep 16 '16 at 17:06
  • I know it sounds ridiculous...but it is possible if a very specific kind of rootkit was programmed and compiled on the system. I see years ago a rootkit that can produce a similar effect on my server. So if a user runned this kind of rootkit in a buggy kernel all the operating system becomes read write, and the permissions dont make sense for any user anymore. If you really are not using root, please try to upgrade your kernel and run chkrootkit... But it is really rare to find a hacker with such abilities, i never see any about this on the network anymore (ext2 module buggy?)... – Luciano Andress Martini Sep 16 '16 at 18:10
  • A possible simple answer: ACLs. – mdpc Sep 17 '16 at 0:28

In simple cases, with a filesystem that consists on files on a local disk, the filesystem driver¹ reads permission metadata (traditional Unix user and group ownership and rwxrwxrwx permissons, access control lists, etc.) stored on the disk according to the filesystem format, and decides whether to grant access based on these permissions. But when there are more layers between the on-disk representation and the application, the permission metadata used for access control and the permission metadata reported through the metadata access interface may not match.

When you run ls, it uses the metadata access interface to display permissions and ownership. When the filesystem is a remote one, the local filesystem driver sends a metadata query to the remote filesystem. When you try to access a file (e.g. when you read it by opening it in an application), with a remote filesystem, the local filesystem driver sends a read request to the remote filesystem. The two may not be consistent if the remote filesystem's responses are incoherent.

It's possible for the remote filesystem's reponses to be incoherent when the remote filesystem supports metadata that the local filesystem doesn't. For example, if the remote server has accounts that the local client doesn't have, the filesystem cannot report metadata accurately. This is pretty common when the server and the client run different operating systems (e.g. Windows server and Linux client or vice versa).

In your case, evidently, either the remote filessytem server is not configured in the way user01 desired or the permissions on the server are not as restrictive as expected. For example there may be an extra ACL entry that grants access to (some) remote users. If the remote filesystem can only report Unix permissions but not richer ACL, you'd see a file owned by the user, with no “group” or “other” permissions, and with an owner who isn't you, but there could be an ACL entry that grants you permission.

¹ This may be subdivided into a type-specific filesystem driver and a generic layer (typically called VFS), but this is system-dependent so I'm purposefully not making the distinction here.

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.