| Subject: | kuserok needs to check for uid 99 on Mac OS X |
On Mac OS X the uid "99" means "owned by everyone". It is used when the
"ignore permissions" checkbox is checked for a volume. Non-root users
will see all files on such volumes as owned by themselves. However, on
Tiger, root processes now see the actual uid of 99.
Currently if a root process calls kuserok() on a user whose home directory
is on a volume with ignore permissions set, kuserok() will fail because the
.k5login file will be accessible, but owned by uid 99 instead of the usual 0
or the user's uid. This is breaking sshd when logging in as users whose
homedirs are on firewire drives (which default to ignore permissions).
The following macro should probably be used for the check:
/usr/include/hfs/hfs_mount.h:#define UNKNOWNUID ((uid_t)99)
If we decide not to fix this, I would at least like to see a specific error come
out of kuserok() in this case. I spent nearly a day debugging this and only
figured it out after stepping through kuserok(). Not something I'd ask a
sysadmin to do.
"ignore permissions" checkbox is checked for a volume. Non-root users
will see all files on such volumes as owned by themselves. However, on
Tiger, root processes now see the actual uid of 99.
Currently if a root process calls kuserok() on a user whose home directory
is on a volume with ignore permissions set, kuserok() will fail because the
.k5login file will be accessible, but owned by uid 99 instead of the usual 0
or the user's uid. This is breaking sshd when logging in as users whose
homedirs are on firewire drives (which default to ignore permissions).
The following macro should probably be used for the check:
/usr/include/hfs/hfs_mount.h:#define UNKNOWNUID ((uid_t)99)
If we decide not to fix this, I would at least like to see a specific error come
out of kuserok() in this case. I spent nearly a day debugging this and only
figured it out after stepping through kuserok(). Not something I'd ask a
sysadmin to do.