简体   繁体   中英

How to securly set flags with open()?

In this question: What's the connection between flags and mode in open file function in C

In comments:

question

If I create a file using 'S_IRUSR' as the mode bit in the first open(), then others call open() using ''O_RDONLY" as flag will not be able to read the file

answer

The same user will be able to read the file. And, just a technicality, it's not that the other users won't be able to read the file, it's that they won't be able to open the file

So I have asked what is the point of setting permission when opening (resp. creating) new file, and that's why I am asking here. There is also mentioned:

They may, as an extreme example, have write access to the directory meaning they could rename your file, copy it to the original name, have access to that then delete your renamed one. Permissions do work but you have to ensure they're set up correctly (like securing the entire path leading to a file, not just the file itself.

So I do not understand what "set flags correctly" means. And also still do not understand the purpose of permission setting, when it is not secure. Can someone explain a little bit?

So I have asked what is the point of setting permission when opening (resp. creating) new file, and that's why I am asking here. There is also mentioned:

They may, as an extreme example, have write access to the directory meaning they could rename your file, copy it to the original name, have access to that then delete your renamed one. permissions do work but you have to ensure they're set up correctly (like securing the entire path leading to a file, not just the file itself.

The comments presented in the quotation are partially incorrect . It is true that a person with write permission on the directory but no permissions at all on the file could rename the file or remove it ( in / from that directory , see below). It is also true that having thereby cleared the way, the same person could create a new file, readable to them, with the other's original name. It is un true, however, that such a person could copy the original file, whether to its original name or to any other, or could use such a maneuver to read the original file.

A key point here is that a directory entry for file F in directory D is just data in a special kind of file: a mapping from a name to an entry in the underlying filesystem. The entry is part of D , not part of F , so manipulating it requires access to D , not to F . What people commonly refer to as a file's name is not actually part of that file at all, nor is it necessarily unique, for the same underlying file can be linked to the directory tree in multiple places, with the same or different names.

A second key point is related to the first: the permissions of a file reside in the filesystem, not in directory listings, and they are effective at controlling access to the file's contents. This is in fact the same for directories as for other kinds of files: a user needs read permission on a given directory to read its contents, and needs write permission on it to modify its contents. Thus, files' access-control attributes do serve a useful purpose, and they need to be set appropriately for files to adequately serve their intended purpose .

The answer to the first part of the question is thus twofold:

  • A file's access-control attributes are an inherent part of that file's filesystem metadata, so there is no avoiding them being set to something when the file is created.
  • You cannot defer permission setting when you're opening a file (name) that does not yet exist but that you are willing to create, because the system will use the file's initial permissions to check access for opening the newly-created file. The appropriate permissions for the file are not derivable from the requested open mode.

The answer to the second part is much simpler: you must specify an access mode when you attempt to open a file because that's how and when the OS enforces access control . Additionally, you may specify a mode that is more restrictive than is permitted to you as an internal control against mistakenly performing unintended actions on the file.

I do not understand what "set flags correcly" means.

The comment seems clear enough to me, especially in light of the example attached to it, but perhaps it would be clearer to you if the larger statement containing it were rewritten as "you need to take these considerations into account, with respect not just to the file itself but also to every directory in the path to it, to ensure that file permissions correctly address your security goals".

I will try to explain it as short as possible. If you execute 'ls -la' somewhere in your file system, you can see something similar to the file list below. It displays the basics of permissions on file systems on Linux and similar operating systems. Running 'man chmod' explains it in detail; you should see 'man 3 chmod' function description as well.

Proper setting of permissions of files and directories, among other settings, is essential for security. Basically, user should have minimal privileges to accomplish his legal task.

drwx r-x r-x  2 root root    4096 Dec 14 23:55 .
drwx r-x r-x 24 root root    4096 Dec  5 19:02 ..
-rwx r-x r-x  1 root root 1113504 Jun  7  2019 file1
-rwx r-x r-x  1 root root  748968 Aug 29  2018 file2
-rwx r-x r-x  1 root root   34888 Jul  4  2019 file3
...
-rwx r-x r-x  1 root root   34888 Jul  4  2019 file_n
 ^^^ ^^^  ^^^ 
  |   |   |  
  |   |   +---------------------- permissions other users  
  |   +-------------------------- permissions for group members
  +------------------------------ permissions for owner
  d  - is a directory
  r  - read permission
  w  - write perrmision
  x  - execute permission

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM