Signs of Triviality

Opinions, mostly my own, on the importance of being and other things.
[homepage] [index] [] [@jschauma] [RSS]

Mac OS X: readlink(2)

Integrating Mac OS X Tiger into our existing NFS/NIS network has proven to be, shall we say, not entirely uninteresting. For one thing, NIS under Mac OS X Tiger does not seem to support supplementary groups! (Update: Mac OS X 10.4.3 does support supplementary NIS groups. I believe earlier versions (pre-tiger) did so as well.) As for NFS, consider the following setup:

The NFS server exports /home to all clients. /home contains symbolic links pointing to the actual location of the users home directory, which is located on another export. For example:

$ ls -ld /home/jschauma
lrwxr-xr-x  1 root  wheel  31 May 29  2001 /home/jschauma ->

The client NFS mounts /home and /usr/people, and everything should work just fine.

Now, when letting users log into the Mac OS X clients, it turns out that a few number of users can log in, but get the error message that the user's ``home directory was not found in the usual place or cannot be accessed''. However, the users files in his home directory are available and his preferences are saved.

Poking around reveals that the permissions on the symbolic link of those users were:

$ ls -ld /home/username
lrwx------  1 root  wheel  [some date] /home/username ->

Note: on Mac OS X, this command would have yielded:

$ ls -ld /home/username

ls: /home/username: Permission denied
lrwx------  1 root  wheel  1 Sep 22 14:58 /home/username

So... this error message only happens if the symbolic link in /home itself (ie /home/username) was created with permissions that do not allow others to read it (the link, not the directory pointed to by the link!). If opened in the 'Finder', the link would show as a regular, inaccessible file. It seems that on Mac OS X (or Darwin?) the file permissions of a symbolic link are actually considered. Note, however, that stat(2) on that platform actually states:

Unlike other filesystem objects, symbolic links do not have an owner, group, access mode, times, etc. Instead, these attributes are taken from the directory that contains the link.

This does not seem to be the case, as in this example /home is mode 755. So, in order to get rid of the warning (which is inaccurate and actually benign anyway), the symbolic links had to be removed on the NFS file server and recreated with the proper permissions.

For comparison: under Linux (or at least this particular instance of Linux), ln(1) always creates symbolic links in mode 777, regardless of your umask. NetBSD, FreeBSD and IRIX create the link with the permissions as modified by your umask, but ignore the permissions when readlink(2)ing it.

September 22, 2005

[Mac OS X: attaching drives] [index] [XServe and locking drives]