Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the 'Consistent UIDs may solve file transfer issues' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Consistent UIDs may solve file transfer issues
Authored by: whoadoggy on Oct 26, '05 07:13:40AM

A related question (that may belong better in the forums) is that I find each new user is also given his/her own group ID (GID). The makes it harder to share folders among group members. Is there a good reason for this? Any way to change the default behavior? Is it better to change the GID to match the group you want to join or to add the member to the group?

Ultimately why would each user want a unique GID? Sorry if this isn't the best place for this question, but it is apropos.



[ Reply to This | # ]
Consistent UIDs may solve file transfer issues
Authored by: i5m on Oct 26, '05 08:26:11AM

I did try this by also adding all users to a new group. I think I used a piece of software called "Share points" for this. I had better luck with this than NetInfo.



[ Reply to This | # ]
Why UID=GID
Authored by: gshenaut on Oct 26, '05 12:27:50PM
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

defaults write -g NSUmask 2
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

[ Reply to This | # ]

... and ACLs
Authored by: sjk on Oct 26, '05 10:47:00PM
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.

[ Reply to This | # ]