|
|
Why UID=GID
This is an old UNIX debate, which has been won for the most part by the UID=GID faction.
The classic model is to have all users assigned to a default group, like "user" or whatever. This is simple, but it means that if you turn on group permissions to a resource, everyone in the "user" group (that is, everyone) has access to it. This is redundant, since there are "other" permissions for that purpose. Therefore, for protection, the umask is set in such a way (022) as to prevent everyone from having write access. However, this setting for umask makes it difficult to use the GID for resource sharing, because files must be created without group write permission. The current model gives each user a unique GID matching the UID. Under this model, the umask should generally be set to 002, because enabling group write access by default does no harm, since each person has his own group. As a result, people can now create additional groups for specific purposes and assign users to them (typical examples are things like bin, web, lab, proj023, and so on). Since files inherit group ownership from the parent directory, then with a default umask of 002, you can set up group-specific directories in which members of the group can all read and write the files; it's very easy and works great. Sometimes even when the UID=GID model is used, the umask is sometimes left as the default 022; this isn't a security problem, but it prevents the group file-sharing I just described. To take advantage of the possibilities in the UID=GID model, you need to run your shell's umask command at some point in the start-up. You should also use so that non-shell commands do this correctly.
You can get more info about the user, group, other permissions with "man chmod", and read a bit about umask with "man 2 umask". Greg Shenaut
... and ACLs
Nice explanation of those issues. Some mention of how ACLs (new in 10.4) attempt to solve certain permission issues would be relevant but that's more for OS X Server than Client. "Grokking Darwin ACLs" is a good overview of that topic.
The UNIX permission system is near the top of my list of "legacy" components that are overdue for replacement. It was designed for handling relatively small numbers of non-networked files and users. It simply doesn't scale well with growth, obviously. ACLs may provide some temporary relief but they add a layer of complexity and new issues while avoiding the real underlying problems. |
SearchFrom our Sponsor...Latest Mountain Lion HintsWhat's New:HintsNo new hintsComments last 2 daysNo new commentsLinks last 2 weeksNo recent new linksWhat's New in the Forums?
Hints by TopicNews from Macworld
From Our Sponsors |
|
Copyright © 2014 IDG Consumer & SMB (Privacy Policy) Contact Us All trademarks and copyrights on this page are owned by their respective owners. |
Visit other IDG sites: |
|
|
|
Created this page in 0.27 seconds |
|