You'll get your Mac news here from now on...

Help TMO Grow

Subscriber Login

Advertising Info


The Mac Observer Express Daily Newsletter


More Info

Site Navigation

Home
News
Tips
Columns & Editorials
Reviews
Reports
Archives
Search
Forums
Links
Mac Links
Software
Reports
Contact


by Kyle D'Addario
& Wincent Colaiuta


Unlocking The Power Of Groups In Mac OS X
April 27th, 2001

In my last column I looked at Mac OS X's inbuilt file-sharing capabilities. This week I look at using users and groups to more finely control other users' access to your files. All of the following assumes that you have administrator and root access to your machine.

A hypothetical project

Imagine that you run a company and you have three folders that you wish to share with various groups, as shown below.

The "Accounts" folder contains top-secret financial documents and you don't want anybody to be able to see them apart from the upper management staff. "Reports" is just stuff about the company's performance that you are happy for any employee or visitor to read, but you want to make sure that they don't write to that directory. Finally, "Project X" contains files relating to one of your company's ventures and this one is a little more complicated: you want some upper management staff and some other employees to have read and write access to this folder, but only those involved with the project. How will you achieve this kind of control?

Conceptual solution of the problem

In Mac OS X, each file and folder has an owner, a group and a set of permissions. You can use these to control who has the ability to read, write and execute an object. In effect, you specify a permission attribute for the object which says, "The owner of the object may do this, the members of the object's group may do this, and everybody else may do this." So, to solve the little problem above, we'll want the following:

  • The "Accounts" folder:
    • The owner will be able to read, write and execute anything
    • Upper management will be able to read only - note that this means we need a special group for the upper management
    • Everybody else will have no access at all
  • The "Reports" folder:
    • The owner will be able to read, write and execute anything
    • All employees will be able to read only - we'll need to create a group for all employees
    • Everybody else will be able to read only
  • The "Project X" folder:
    • The owner will be able to read, write and execute anything
    • People working on the project will have read and write access - we'll need to create a group just for the project staff
    • Everybody else will have no access at all

Putting our plan into action

We'll be using the NetInfo Manager application (located in Applications/Utilities) to set up the needed groups, and then we'll make sure that each group contains the appropriate users, and finally we'll set the correct permissions for the folders. The screenshot below shows a glimpse of what we'll be doing in the NetInfo Manager:

First up we need to click the padlock and enter our administrator password so that we can make changes. If you click on the groups folder in the listing, you will see a list of all the groups on the machine: admin, nobody, staff, wheel and others. For the purposes of this exercise, I'll just use the "staff" group to represent upper management. These are people with root access to the machine. So my first task then is to create a group called "projectx" and make sure that all the members of the project are listed in that group.

The easiest way to do this is to copy an existing group and then edit it. From the groups list, select the admin group and click the duplicate button (a picture of two folders). From there you will be able to rename the group to "projectx" by clicking on the new group and then clicking inside the name field (which appears in the bottom pane of the NetInfo window). We also need to assign the group a unique group id number (gid). In the example above I decided that 400 would be a good number, after checking through the other groups to make sure that that id wasn't already in use.

I was already listed as one of the users in that group, so I needed to add the employee who was also working on the project, my serving boy, "sho." I did this by selecting the "users" field of my "projectx" group and choosing "Insert value" from the "Directory" menu. I could keep doing this until all of the members of staff working on the project were listed.

Much the same procedure can be followed for creating the "employees" group. We copy an existing group (this time the "projectx" one that we just created), assign it a unique gid (this time we'll use 401), and make sure the right users are listed as members.

Using the terminal to set groups and permissions

I am first going to show you how to set the permissions with the command line in the terminal. For those of you who don't want to get their hands dirty with this sort of thing, I have tips below for doing all of these tasks with GUI apps. In the terminal (located at Applications/Utilities), I find the directory I am working on and type "ls -laF". This is the output that I get:

drwxr-xr-x   6 wincent  staff   160 Apr 26 14:27 ./
drwxr-xr-x  16 wincent  staff   500 Apr 26 14:34 ../
drwxr-xr-x   2 wincent  staff   264 Apr 26 14:26 Accounts/
drwxr-xr-x   2 wincent  staff   264 Apr 26 14:26 Project X/
drwxr-xr-x   2 wincent  staff    24 Apr 26 14:27 Reports/
If you examine the "Accounts" line from left to right you will see the following facts about that folder: it is a directory (d); the owner can read, write and execute (rwx); the members of its group can read and execute but not write (r-x); ditto for everybody else (r-x); the owner is "wincent" and the group is "staff." Our other folders also have the same ownership, groups and permissions. We'll need to change this to suit our goals, by changing to root (type "su" in the terminal and then enter your root password) and entering the following:
chgrp projectx 'Project X'
chgrp employees Reports
chmod 750 Accounts
chmod 770 'Project X'

The first line simply assigns the "projectx" group that we just created to the "Project X" folder. Similarly, the second line assigns group "employees" to the "Reports" folder. We won't bother to change the group of the "Accounts" folder because it's already associated with group "staff," just like we want. I'll explain the next two lines in more detail further on, but for now what we've done is change the permissions on the two folders to which we want to restrict access. Typing "ls -laF" again shows us the fruits of our changes:

drwxr-xr-x   6 wincent  staff      160 Apr 26 14:27 ./
drwxr-xr-x  16 wincent  staff      500 Apr 26 14:34 ../
drwxr-x---   2 wincent  staff       24 Apr 26 14:26 Accounts/
drwxrwx---   2 wincent  projectx    24 Apr 26 14:26 Project X/
drwxr-xr-x   2 wincent  employee    24 Apr 26 14:27 Reports/

Notice what is different now: "Accounts" is no longer readable and executable by anybody outside the "staff" group; "Project X" is now associated with group "projectx" and members of that group can read, write and execute (rwx) but nobody else can; and "Reports" is now associated with group "employees."

Now all of this was pretty straightforward, except for the changing of permissions. What did those statements "chmod 750" and "chmod 770" mean? Mac OS X uses a special number system to represent permissions. Execute access is represented as a "1," write access is represented as a "2," and read access is represented as a "4." So do you want to give read, write and execute access? Just add them up (ie. 7). Want to give only read and execute? Add the relevant values and you'll get 5. Want to deny all access? Just specify zero.

You'll notice that in our directory listings the permissions are listed in the order owner, group, world (ie. everybody). The same pattern is followed in our chmod statements; so in "chmod 750," this means "give access of 7 to the owner, access of 5 to the group, and access of 0 to everybody else". A quick calculation shows that the permission number 750 corresponds to our desired access pattern of rwxr-x---.

Bypassing the command line

If all of that sounded a little bit frightening and un-Mac-like to you, fear not: there are several ways of doing exactly the same operation via the graphical user interface instead. Firstly there is Apple's "Show Info" inspector in the Finder (which you can bring up by pressing command+I and selecting "Privileges" from the popup menu):

As you can see, this can be used for setting permissions, but not for assigning groups. An alternative is Gideon Softworks' "GetInfo" program shown below, where the relationship between the graphical controls and the underlying Unix command-line instructions is a little clearer:

But this still doesn't help us to change groups using a graphical interface. For that we'll need to try out xFiles by Brian Hill. As shown in the screenshot below, xFiles permits us to type in a new group or owner as well as providing controls for setting permissions and much more. (Incidentally, Brian's page features a lot of other useful applications, including one called Pseudo which is useful for running graphical applications as root.)

Conclusion

As you can see, managing users and groups under Mac OS X is a far cry from the "Users and Groups" control panel of Mac OS 9. The Unix underpinnings of the OS are really making themselves felt, but with a twist because adding groups requires the use of the NetInfo Manager instead of the command line tools which will be familiar to Unix veterans. I expect that in the future Apple will release some simple tools that make all this much, much easier. After all, Apple prides itself on its ease of use. Given that Mac OS X is still so fresh and new, it's to be expected that there should be some rough edges. In the meantime though, I hope this little tutorial has helped shed some light on the subject for you all.

-Wincent Colaiuta

You are encouraged to send Richard your comments, or to post them below.


Most Recent Hot Cocoa Columns

Mac OS X & Firewalls: Part One - The Basics
August 17th

Console Yourself: Understanding Mac OS X Logs
August 3rd

Making NFS Work On Mac OS X
July 23rd

Hot Cocoa Archives

Back to The Mac Observer For More Mac News!


Kyle D'Addario is the assistant editor of The Mac Observer and has logged about as much time on Mac OS X as is humanly possible. Kyle studies Computer-Mediated Communication, whatever that is, at the graduate level, and was a founding member of the original Webintosh team.


Wincent Colaiuta runs Macintosh news and criticism site, wincent.org, and joined The Mac Observer team as a contributor in March 2001. He has worked with computers since 1984, and his interests in that area include Macs, PHP programming and security.



Today's Mac Headlines

[Podcast]Podcast - Apple Weekly Report #135: Apple Lawsuits, Banned iPhone Ad, Green MacBook Ad

We also offer Today's News On One Page!

Yesterday's News

 

[Podcast]Podcast - Mac Geek Gab #178: Batch Permission Changes, Encrypting Follow-up, Re-Enabling AirPort, and GigE speeds

We also offer Yesterday's News On One Page!

Mac Products Guide
New Arrivals
New and updated products added to the Guide.

Hot Deals
Great prices on hot selling Mac products from your favorite Macintosh resellers.

Special Offers
Promotions and offers direct from Macintosh developers and magazines.

Software
Browse the software section for over 17,000 Macintosh applications and software titles.

Hardware
Over 4,000 peripherals and accessories such as cameras, printers, scanners, keyboards, mice and more.

© All information presented on this site is copyrighted by The Mac Observer except where otherwise noted. No portion of this site may be copied without express written consent. Other sites are invited to link to any aspect of this site provided that all content is presented in its original form and is not placed within another .