Talk:File-system permissions: Difference between revisions

Browse history interactively

← Previous edit Next edit →

Content deleted Content added

VisualWikitext

Inline

Revision as of 06:35, 14 October 2015

Computer Security: Computing Unassessed

This article is within the scope of WikiProject Computer Security, a collaborative effort to improve the coverage of computer security on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Computer SecurityWikipedia:WikiProject Computer SecurityTemplate:WikiProject Computer SecurityComputer Security articles

???

This article has not yet received a rating on Wikipedia's content assessment scale.

???

This article has not yet received a rating on the project's importance scale.

This article is supported by WikiProject Computing.

Things you can help WikiProject Computer Security with:

Article alerts will be generated shortly by AAlertBot. Please allow some days for processing. More information...

Review importance and quality of existing articles
Identify categories related to Computer Security
Tag related articles
Identify articles for creation (see also: Article requests)
Identify articles for improvement
Create the Project Navigation Box including lists of adopted articles, requested articles, reviewed articles, etc.
Find editors who have shown interest in this subject and ask them to take a look here.

Computing Unassessed

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
???	This article has not yet received a rating on Wikipedia's content assessment scale.
???	This article has not yet received a rating on the project's importance scale.

Origins

Did file system permissions realy originate with Unix? Does there exist more background history somewhere?

A reader suggested the move of the initial permissions page to file system permissions. I aggread with that and added some more text in the document.

The section on Octal notation is incomplete. The first digit of a four-digit octal permission set denotes something. It might be the file type or the additional permissions. I'm not sure which, and I don't know what values would be acceptable.

Much of this terminology is conjectural. Any clarification or modification thereof would be appreciated.--Kbolino 00:21, 30 Jan 2005 (UTC)

The octal notation section is complete (note: 'Octal Notation and additional permissions' section). The first digit on a 4-digit octal permission is the suid/sgid/sticky bits. The section is worded in a dry manner. This could be cleaned up. I know that file system permissions didn't originate on Unix. Multics had file permissions as well.

There is a noticeable lack of the last octal group for suid, guid and sticky.

—The preceding unsigned comment was added by Jharr (talk • contribs) 14:38, 18 October 2006.

Mac OS X and Unix permissions

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)[reply]

Read-while-write

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)[reply]

non-standard permission flags

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) (de:Benutzer:RokerHRO)[reply]

Hmm?

"Differences between operating systems"

Shouldn't that be "Differences between file systems"? — Omegatron 20:54, 17 November 2007 (UTC)[reply]

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)[reply]

adding links to lsattr and chattr

they are indirectly related to permissions. --xenoterracide —Preceding comment was added at 23:16, 21 March 2008 (UTC)[reply]

INACCURACY: OS X leopard server has ACL's enabled by default

I just read in a mac support forum on apples site that OS X leopard server has ACL's enabled by default. This is contrary to the first paragraph's assertion that "all versions of OS X use POSIX permissions" and "no OS implements ACL's"

I don't know enough to research this further, and I'm afraid I don't know where on the forum I saw this... sorry.

What's mentioned here about VMS permissions is wrong

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)[reply]

Why is the differences section first?

--betaneptune

Why it this so Unix-centric?

--betaneptune

Because no one has added information on other systems! DGerman (talk) 22:15, 16 December 2012 (UTC)[reply]

Why the complicated explanation of octal permissions?

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)[reply]

Merge with share permissions (or not)

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)[reply]

That's just silly. You were thinking of ACLs, right? And that share permissions should redirect there?--JeR (talk) 13:10, 16 September 2010 (UTC)[reply]

Packed permission bits?

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)[reply]

It's "Mode" not "Permissions"

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)[reply]

These MODE bits define the permissions given to others, come on. DGerman (talk) 02:15, 17 April 2013 (UTC)[reply]

Standard permissions

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)[reply]

+ and . suffixes to the file permissions

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)[reply]

Article title - filesystem as one word

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)[reply]

Requested move

The following discussion is an archived discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.

The result of the move request was: page moved. Armbrust ^{The Homunculus} 10:09, 17 October 2013 (UTC)[reply]

Filesystem permissions → File system permissions – "file" and "system" are separate words, and we have the article File system Mitch Ames (talk) 13:50, 10 October 2013 (UTC)[reply]

Support. On Unix descendants the term is nearly always "filesystem", but the present article does not only cover Unix descendants. Using common English idiom is preferable. 168.12.253.66 (talk) 14:16, 10 October 2013 (UTC)[reply]
Support, looks a more natural title. Diego (talk) 14:49, 10 October 2013 (UTC)[reply]

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

Operating system variations

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)[reply]

Cannot understand the Notation of traditional Unix permissions / symbolic notation section

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.

In the first triad the characters  "s" and "S" are equivalent respectively to "x" and "-"  with the extra setuid bit. In the second triad the characters  "s" and "S" are equivalent respectively to "x" and "-"  with the extra setgid bit. In the third triad, the characters "t" and "T" are equivalent respectively to "x" and "-" with the extra sticky bit.

Of course, someone has to check whether this is correct. One thing is certain, it is not clear as it is. — Preceding unsigned comment added by 70.27.226.36 (talk) 01:50, 14 October 2015 (UTC)[reply]

@@ Line 143: / Line 143: @@
 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.
- In the first trial the characters  "s" and "S" are equivalent respectively to "x" and "-"  with the extra setuid bit. In the second trial the characters  "s" and "S" are equivalent respectively to "x" and "-"  with the extra setgid bit. In the third trial, the characters "t" and "T" are equivalent respectively to "x" and "-" with the extra sticky bit.
+ In the first triad the characters  "s" and "S" are equivalent respectively to "x" and "-"  with the extra setuid bit. In the second triad the characters  "s" and "S" are equivalent respectively to "x" and "-"  with the extra setgid bit. In the third triad, the characters "t" and "T" are equivalent respectively to "x" and "-" with the extra sticky bit.
 Of course, someone has to check whether this is correct. One thing is certain, it is not clear as it is.  <small class="autosigned">—&nbsp;Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/70.27.226.36|70.27.226.36]] ([[User talk:70.27.226.36|talk]]) 01:50, 14 October 2015 (UTC)</small><!-- Template:Unsigned IP --> <!--Autosigned by SineBot-->