Talk:File-system permissions

message: Did file system permissions realy originate with Unix?  Does there exist more background history somewhere?
:Clearly not.  Unix was born about 1972.  The Michigan Terminal System was created in the mid-1960s (operational 1967) and had a superset of what became the Unix set of permissions.  MTS had read, write/change, write/append, truncate/renumber, destroy/rename, and permit (the ability to change the ACL list).  In the file catalog entry (i.e. a single level directory structure), it had the owner and others permissions.  All other permissions were done via an ACL list which allowed permissions keyed to user, project (group), "program key", and user or group in combination with program key.  Every executable (a file readable by the system dynamic loader routine) could set a program key (which need not be unique).  Some of the OS subsystems also possessed such keys.  An execute-only file was created by giving read-only access to the loader's key in combination with no other access granted to the current user or his project (usually by defaulting to "others none").  The file owner always had permit access even when the bit indicated no such access.
:MIT also had Multics but I am unfamiliar with it.  I have heard that "unix" is a portmanteau for "[single] user multics." 2001:470:D:468:7455:7A:1C17:3DB4 (talk) 04:21, 10 August 2017 (UTC)
thread_title:  Origins 

message: I'm pretty sure Mac OS X does use traditional Unix-style premissions. The core of the operating system (Darwin) is Unix-based and exhibits all the characteristics of a typical Unix system. When I repair my disk permissions, they are set to Unix style permissions. Theshibboleth 20:57, 8 November 2006 (UTC)
replies: text: Yes, it does, and the article currently says so. Guy Harris (talk) 21:05, 6 June 2022 (UTC)
thread_title:  Mac OS X and Unix permissions 

message: Read-while-write redirects here, but there is no deeper discussion on this topic. I also hear this phrase in other context than FS permissions, such as EEPROM and flash memory. So what does it mean? --Abdull 16:04, 7 March 2007 (UTC)
thread_title:  Read-while-write 

message: I remember vaguely that I've seen some more exotic, non-standard permission flags as output of 'ls'. I beleave it was an e and a... Do or did such permission bits exist or am I deceived? --84.72.190.27 13:49, 12 March 2007 (UTC)
thread_title:  non-standard permission flags 

message: "Differences between operating systems"
Shouldn't that be "Differences between file systems"? — Omegatron 20:54, 17 November 2007 (UTC)
replies: text: Usually the OS sets the file system permission model. if a filesystem doesn't fit with the model of the OS (e.g. when NTFS is implemented on a unix linke system) then the implementation usually ends up without usable permission support at all. Plugwash (talk) 02:04, 18 November 2007 (UTC)
thread_title:  Hmm? 

message: they are indirectly related to permissions. --xenoterracide  —Preceding comment was added at 23:16, 21 March 2008 (UTC)
thread_title:  adding links to lsattr and chattr 

message: VMS has 4 categories (system, owner, group, world) and 4 "permissions" (read, write, execute, and delete) in addition to ACLs. I'll fix this later when I have more time. --betaneptune  —Preceding unsigned comment added by 209.191.171.11 (talk) 17:21, 5 June 2009 (UTC)
thread_title:  What's mentioned here about VMS permissions is wrong 

message: --betaneptune
Because no one has added information on other systems! DGerman (talk) 22:15, 16 December 2012 (UTC)
thread_title:  Why it this so Unix-centric? 

message: Just put a '1' under each letter and a '0' under each dash.
Example:
    -rwxr-x--x
     111101001
This gives 111 for user, 101 for group, and 001 for other. In binary these immediately translate to 7, 5, and 1. So the octal code for this example is simply 751. Why all the extensive explanation of adding 4 and 2 and 1 and 100 and 010 and 001 and such? It's really very simple. 
--betaneptune
simple if you know the ambiguity inherent in the radix always being 10 168.251.194.25 (talk) 17:49, 3 June 2010 (UTC)
thread_title:  Why the complicated explanation of octal permissions? 

message: share permissions is the windows centric version of this which is the Unix angled one.  I think there could be a generic article, and also specific ones for major operating systems.  The names for these articles could be the terms used in those operating systems. Graeme Bartlett (talk) 07:09, 31 December 2009 (UTC)
thread_title: Merge with [[share permissions]] (or not)

message: I came to this page looking for verification of packed permission bit format, which as I understand it is a space optimization allowing two rather than three bits for storing each permission -- entirely abstracted away by implementations.
The way the optimzation works is, since go, uo, ug, and ugo permissions can be represented by (respectively) o, o, g and o permissions, those four are not needed and the four remaining possibilities for each of r,w,x can be packed into two bits instead of three.
http://www.cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping describes a problem in attempting to map a posix permission of rw-r-xrw- into Windows Access Control Entities. I'm not certain that this problem is real, as it isn't clear that granting write to o but not g is possible. It would not be possible with a packed representation. 168.251.194.25 (talk) 17:59, 3 June 2010 (UTC)
thread_title:  Packed permission bits? 

message: Unix, Linux and BSD files have "file mode bits" that collectively are referred to as a file's mode. See the man page for the command used to modify them: chmod.
Extended attributes are referred to as "attributes". See the man page for lsattr.
Kernel.package (talk) 04:18, 24 May 2011 (UTC)
thread_title:  It's "Mode" not "Permissions" 

message: Standard permissions I believe refers to read, write and execute for the three groups user, their group and everybody.  Where as ACL's over ride standard permissions and often we need some sort of ACL inspector to determine the "effective permissions".  These general characterizations help me better understand different file systems.  — Preceding unsigned comment added by 110.174.98.26 (talk) 09:58, 3 October 2012 (UTC)
thread_title:  Standard permissions 

message: The + suffix indicating an ACL is present is a significant security hole if not understood by users, and it's poorly documented and not widely known, so I've added links as clearly and concisely as possible to the bottom of standard permissions.
Andy Henson. 82.152.115.137 (talk) 10:04, 13 December 2012 (UTC)
thread_title:  + and . suffixes to the file permissions 

message: Why is the article titled with the single word "filesystem"? Surely file system is the more common term? Mitch Ames (talk) 12:23, 17 September 2013 (UTC)
replies: text: It's my impression that it's pretty much 50/50 split, with single word being the slightly more dominant variant.  — Preceding unsigned comment added by 185.107.15.50 (talk) 19:36, 5 June 2021 (UTC)
thread_title:  Article title - filesystem as one word 

message: I recommend that the Operating system variations section be retitled and rewritten as File system variations.  The differences in permissions support are specific to the file system in use rather than the operating system in general.  A drive formatted as FAT or FAT32 has no permissions, no matter what operating system it is used with.  -- Dave Braunschweig (talk) 20:51, 1 March 2015 (UTC)
thread_title:  Operating system variations 

message: The table is not clear regarding the setuid/setgid or sticky bits. I wanted to learn how to interpret "s" and "t" in the output of "ls -l" and it was not useful. My guess, but I could be wrong, is that "s" or "S" can only appear in the first or second trial whereas "t" or "T" can only appear in the third trial.  If that it is the case, it starts to make sense, because then we can use the trial to determine whether "s"/"S" is setuid or setgid. In that view, "s"/"S" in the third trial would not make sense. Also, if we used "t"/"T" in the first or second  trial, there will be no room for setuid and sticky at the same time. By using "t"/"T" on the third trial only, we are OK, because "s"/"S" and "t"/"T" use different trials. If this is the correct understanding, it definitively needs a little bit more explanation.  There should be some explanation in the main text about the characters "s", "S", "t" and "T" that are present in the table. I would thing that adding the three following sentences would be useful.  
 To set the setuid bit, in the triad for the user, we use "s" instead of "x" and "S" instead of "-". To set the setgid bit, in the triad for the group, we use "s" instead of "x" and "S" instead of "-".  To set the sticky bit, in the triad for others, we use "t" instead of "x" and "T" instead of "-".  
Of course, someone has to check whether this is correct. One thing is certain, whether it is correct or not, the section is not clear as it is.  — Preceding unsigned comment added by 70.27.226.36 (talk) 01:50, 14 October 2015 (UTC)
thread_title:  Cannot understand the Notation of traditional Unix permissions / symbolic notation section 

message: This article says that in Unix-like systems The write permission grants the ability to modify a file.
In other words, a file without write permission is unmodifiable.
That is not true. In GNU bash (version 4.4.7) anybody can reproduce this:
 $ ls -gGid --time-style=iso . *
 3965287 drwx------ 2 2048 06-09 19:02 .
 3965289 -r-------- 1    6 06-09 19:02 myfil
 $ cat myfil
 hello
 $ cp --no-preserve=mode myfil xf
 $ ls -gGid --time-style=iso . *
 3965287 drwx------ 2 2048 06-09 19:11 .
 3965289 -r-------- 1    6 06-09 19:02 myfil
 3965305 -rw-rw-r-- 1    6 06-09 19:11 xf
 $ echo world >>xf
 $ cat xf
 hello
 world
 $ unlink myfil
 $ ls -gGid --time-style=iso . *.      # notice at this point no file named myfil exists
 3965287 drwx------ 2 2048 06-09 19:15 .
 3965305 -rw-rw-r-- 1   12 06-09 19:14 xf
 $ mv xf myfil
 $ ls -gGid --time-style=iso . *
 3965287 drwx------ 2 2048 06-09 19:18 .
 3965305 -rw-rw-r-- 1   12 06-09 19:14 myfil # at this point xf has been "renamed" to myfil retaining rw
 $ cat myfil
 hello
 world
 $
The directory of myfil was writable (to allow creating new files). And this is enough to replace the old myfil with a newer myfil! The inode number changes, but the users do not even notice it, and if so, it is usual for any text editor also to change inode numbers of (writable) files.
So maybe this is a design error (or weakness) in the Unix-like file system? The files, in the common sense, are not protected. Under file it (most likely) means the inode. The inode is (until its quick deletion) protected, but this means not much value for the user.  — Preceding unsigned comment added by VillamGadner (talk • contribs) 18:53, 9 June 2017 (UTC)
replies: text: I must disagree.  The file called "myfil" that you end up with is not the same file you started with.  It is in fact a different file in the file system because it is mapped to a different inode.  Replacing a file with a modified copy is not the same as having write access to the original file just because you have write access to its directory.  You never wrote to the original file, nor could you. 2001:470:D:468:7455:7A:1C17:3DB4 (talk) 04:31, 10 August 2017 (UTC)
thread_title:  "Write-protected" files are in fact NOT protected from writing! FALSE 

message: Several of the paragraphs redundantly say the same things more than once. I have made a few attempts to simplify the article slightly.
DGerman (talk) 19:58, 11 May 2021 (UTC)
thread_title:  words like usually, universally , commonly just add confusion 

message: In TRON, as far as I can tell, it is similar to POSIX file permissions but instead of one bit per permissions, it uses a 4-bit number for each permissions; if it is equal to or greater than the access level number of the process, then it can be accessed. (Zero is the most privileged access level, and therefore can access all files.) --Zzo38 (talk) 05:23, 27 March 2023 (UTC)
thread_title:  File permissions in TRON