0

According to the accepted answer here, it is simply because you would not make the access checks at the directories leading up to that file. For example, with a call to openinode(inode #, flags).

My question is simply: why would the file not already have the necessary access control list by itself (without those leading directories)?

Is there a case where those leading directories (which may have different permissions) become important?

Z0OM
  • 3,149
user129393192
  • 153

2 Answers2

4

Say I have a directory structure containing any number of subdirectories, files, sub-sub-directories and so on. I want to remove access to all of them except for a specific user and group. This is easily done:

chown chosen_user:chosen_group some-directory
chmod ug=rwx,o-rwx some-directory

With your proposed method of having every file contain access controls in its metadata, I'd have to do this (or some other ACL if directly changing user/group is not possible, e.g., setuid binaries) for every single file. Why would anyone want that?

muru
  • 72,889
  • But what if they have a (hard) link to it from elsewhere already? – user129393192 Jun 05 '23 at 04:53
  • Since hardlinks aren't super common, if they have a hard link elsewhere, it's likely I the admin made them, in which I case I'd also have some way of keeping track of hardlinks I made. How many of the files you administer have hardlinks in some other directory? – muru Jun 05 '23 at 05:02
  • I’m just trying to think from a security perspective. To me, it seems a bit sloppy to have the ACL on the directories for the files within, rather than self-contained within the files. I’m sure it’s not difficult to make a simple iterating shell script to remove permissions from a specific user, if that is the goal. Mostly, I don’t see why directories should be the ACL for the files, making openinode unsafe – user129393192 Jun 05 '23 at 05:08
  • Also consider if you aren’t the admin, and they have a hard link somewhere, that you can’t even know exists, because you can’t access the directory … all you see is the link count, making you suspicious. What then? – user129393192 Jun 05 '23 at 05:13
  • If I am not the admin, and I needed to do some actual file access restriction, I'd be asking the admin. – muru Jun 05 '23 at 05:14
  • All I’m saying is I don’t see why the files own set of permissions shouldn’t be the main-sayer, and why leading directory permissions should play a say … from a security perspective, it makes more sense for it to be contained in the file – user129393192 Jun 05 '23 at 05:16
  • And what I'm saying is that there is a benefit to having simpler ways of doing things. Remember: security at the cost of usability comes at the cost of security. Your "security perspective" is quite limited if it doesn't take that into account. – muru Jun 05 '23 at 05:18
  • 1
    Even if you can’t see a hard link, you can still see the hard link count on the file you care about; if it’s 1 you know you’re OK, if it’s more you check your own files then ask the admin. – Stephen Kitt Jun 05 '23 at 05:32
  • Right, so at that point we fall to individual file permissions @StephenKitt if we’d like to disallow a certain user access, so the question remains why openinode is a security issue if these directory permissions are not really doing all that much for the files underneath in the end (and also — why would the files not have the correct permissions to begin with?) – user129393192 Jun 05 '23 at 06:41
  • @user129393192 "all that much" is relative - again, how many hard links do you manage, really? I can count on one hand the number of times I have had to deal with hard links. It's similar to the Pareto principle. – muru Jun 05 '23 at 06:55
  • Directory permissions are doing a lot — they control access to all files underneath them. – Stephen Kitt Jun 05 '23 at 06:55
  • But, fundamentally, why should the files themselves not have the permissions they require, instead of relying on the directories above? I don’t know if I’m beating a dead horse, but to me, the question is still unanswered – user129393192 Jun 05 '23 at 07:15
  • Why force users to always pay attention to all their files’ permissions? If foo sets /home/foo to 700 they can be confident that no one else will have access to files anywhere below (assuming no hard links already exist). You can think of it as belts and suspenders — directory permissions give one level of protection, file permissions another, on top of it. They’re complementary. – Stephen Kitt Jun 05 '23 at 07:36
  • @user129393192 ok, look at it from the other direction. You start with just files, and permissions on those files. At some point, it becomes obvious that you need some way to group those files - and so you get directories. At further on, it again becomes obvious that when you group files, it should also be possible to set permission for the group as a whole. And then you have the current system. – muru Jun 05 '23 at 07:38
  • 1
    @user129393192, why would you lock a room of archives when you could just lock each individual cabinet within it? Or why lock the front door when you could lock all inside doors, etc. – ilkkachu Jun 05 '23 at 12:11
  • You could plausibly have a system that did all access controls on the file level. It'd just be different. – ilkkachu Jun 05 '23 at 12:18
1

Aside from the reasons stated in muru's answer, I'd like to point out that this would run against POSIX/UNIX permission systems and lead to gaping security holes:

Files in POSIX are stored, retrieved, modified, attribute- and privilege-checked by their name and path. That's the fundamental model of a file: Give the operating system a string that describes what piece of data you want to get, which implies a hierarchy of directories you need to go through to get it, and it checks whether you may, and gives you, if OK, the access to that piece of data, in shape of a file descriptor.

There's a well-defined point in time when that access privilege checking happens, and that's when you ask the operating system to "open" a file, as described above.

Introducing any other identifier – not even necessarily an inode number, anything – that doesn't go through that same process of privilege validation is a security mistake on multiple levels!

  • circumvention of the path-based access control: the path having to be accessible by you is a restriction on your privileges to open the file. Using bind mounts, hardlinks, NFS… there might be different ways you open a single file. These might all result in different privileges with which you can (or cannot) access the file. UNIX says: Privilege to do something to a file is not only a property stored in the file system entry for that file alone. Your inode-based access scheme disables that restriction, and hence would circumvent a lot of security.

  • Changes: inodes are, by absolutely no means, not guaranteed to stay constant. Simply not part of the contract.

  • Worse: Exploiting, an example: I want to read a regularly closed/renamed/opened anew access log. I can't, because the path says I can't (e.g. unprivileged user can't read nor execute /var/log/daemon/, even if the file is 644). I just brute force all inodes until I open one that looks right. Tadah.

  • inodes are an implementation detail. Original UNIX file systems had that, and it stuck. There's no reason to assume an inode nr being a "useful" thing to any other / modern file system. In fact, my guess would be, from a pure count perspective, of all the file systems the Linux kernel supports, most do not store inode numbers at all, but these are "emulated" by the kernel.

user4556274
  • 8,995
  • 2
  • 33
  • 37
Marcus Müller
  • 28,836
  • Could you specify how the way you access the file could result in different privileges? Specifically, your first bullet point about the circumvention. Don't you, once you get to the file, have whatever permissions it specifies in its inode (for the file itself) for you? As for your third point, why would the file not have the correct permissions if it's something that secure in the first place? – user129393192 Jun 05 '23 at 22:09
  • no need, explained in my answer :) even illustrated by "Worse:", 2. no, as two answers have explained to you: the path you use to access a file contains restrictions in access that are not contained in the file metadata itself. Note that paths can change without inode nrs changing, as well. 3. Path is part of permissions system. You're trying to ignore that. But it's crucial.
    • – Marcus Müller Jun 05 '23 at 22:10
  • That is not my point. I understand the path imposes its own restrictions. I'm just stating that once you get to the file, don't you have what permissions it specifies? What is the first bullet point saying about how you may have different priviledges based on the path? – user129393192 Jun 05 '23 at 22:12
  • no. paths change. 2. I don't know how to explain my first bullet point any better than my first bullet point. You can access the same file (with the same inode) through different paths, with different restrictions, and you saving that inode now doesn't mean you should still access the file in 1s from now.
    • – Marcus Müller Jun 05 '23 at 22:13
  • I understand. You mean something like mv a file into a directory like lesser permissions. I thought you were specifying underlying device priviledge since you mentioned NFS and bind mount – user129393192 Jun 05 '23 at 22:15