COMMAND
AFP
SYSTEMS AFFECTED
MacOS 9 Multiple Users and Netware AFP
PROBLEM
Don Lambert found following. He ran into a problem with MacOS 9's
Multiple Users feature and Netware AFP. MacOS 9 tries to create
a Users folder at the root level every mounted volume. The
behavior occurs on locally mounted volumes (including SCSI, IDE,
and floppies). It also occurs on volumes accessed by AppleShare.
The Users folder seems to be loosely analogous to the
%System Root%\Profiles\
directories that get created in Windows NT. Unfortunately, Don
wasn't able to find much info on the purpose and functionality of
the Users folder at Apple's site. In the case of MacOS 9 creating
the folder on Netware AFP servers, the resulting Users folder
gives excessive rights (RWCEMF) to [Root]. The problem occurs on
servers running AFP when users connect via AppleShare in the
Chooser. It does not occur when logging in using the Prosoft
Client for MacOS. Don was able to duplicate the problem on both
a Netware 4.11 server and a Netware 5 server. His testing steps
are below. At the end of the advisory he presents a workaround:
Test 1 [Netware 4.11, AFP 4.10, MacOS 9, bindery connection through Chooser]
============================================================================
This test involves AFP 4.10 NLM running on a Netware 4.11 server
(SRVR1). The client side is MacOS 9 running in Multiple Users
mode. Created user - chooseruser in the same container as the
server. Give chooseruser read, create, and filescan to the root
of SRVR1_DATA1 volume. On the MacOS 9 Mac, log into SRVR1 as
chooseruser via a bindery connection through Chooser (no NDS
client involved) and mount DATA1. A Users folder is created at
root of DATA1. Checking in NWADMN32, Don saw that chooseruser is
the Owner of this. No other trustees are listed for the Users
folder. Now he Log out chooseruser from SRVR1 on the Mac. Don
gave chooseruser read, create, filescan, and access control to the
root of SRVR1_DATA1 volume. On the MacOS 9 Mac, log into SRVR1 as
chooseruser via a bindery connection through Chooser (no NDS
client involved) and mount DATA1. A Users folder is created at
root of DATA1. This time when checking in NWADMN32, Don saw that
[Supervisor] is the Owner. When he checked the Trustees, he saw
that [Root] is a trustee with Read, Write, Create, Erase, Modify,
and File Scan, [Supervisor] is a trustee with Read, Write, Create,
Erase, Modify, File Scan, and Access Control.
Now, log out chooseruser and give the account RWCEMFA access to
the root of the DATA1 volume. Log in as chooseruser again through
the Chooser and mount DATA1. When you look at the existing Users
folder, one would expect that you should be able to copy a file to
it. The MacOS says you only have See Folders and See Files
privileges (i.e. read & file scan). It appears that the MacOS is
putting limits on my access to the Users folder over and above
what NDS is doing. When you log into MacOS 9 with a Mac Owner
Account (that's an account run by MacOS 9 Multiple Users), and
then log into SRVR1 as chooseruser, you can mount DATA1 and have
your normal NDS granted access to the Users folder. You also get
the regular access Users folder if you turn off the Multiple Users
functionality and mount the DATA1 volume.
Test 2 [Netware 5, AFP 4.53, MacOS 9, bindery connection through Chooser]
=========================================================================
Test 2 is pretty much the same test as Test 1, but instead of
using Netware 4.11 and AFP 4.10, we'll use Netware 5 and Prosoft's
AFP 4.53 on the server end. The server is SRVR2. The results are
same as in Test 1. The testing steps are below.
Give chooseruser read, create, and filescan to the root of
SRVR2_DATA2 volume. On the MacOS 9 Mac, log into SRVR2 as
chooseruser via a bindery connection through Chooser (no NDS
client involved) and mount DATA2. A Users folder is created at
root of DATA2. Checking in NWADMN32, you see that chooseruser is
the Owner of this. No other trustees are listed for the Users
folder.
Now log out chooseruser from SRVR2 on the Mac. Give chooseruser
read, create, filescan, and access control to the root of
SRVR2_DATA2 volume. On the MacOS 9 Mac, log into SRVR2 as
chooseruser via a bindery connection through Chooser (no NDS
client involved) and mount DATA2. A Users folder is created at
root of DATA2. This time when checking in NWADMN32, you'll see
that [Supervisor] is the Owner. When you check the Trustees,
you'll see that [Root] is a trustee with Read, Write, Create,
Erase, Modify, and File Scan. [Supervisor] is a trustee with
Read, Write, Create, Erase, Modify, File Scan, and Access Control.
Test 3 [Netware 4.11, MacOS 9, Netware Client for MacOS 5.12, NDS Connection using NW Client]
=============================================================================================
This test uses SRVR1, a Netware 4.11 server again. It also uses
MacOS 9 with multiple users and Prosoft's Netware Client for MacOS
5.12.
Next, Don tried the same tests as above, but he used a user called
prosoftuser in the same container as SRVR1. He deleted the Users
folder from the above tests off of DATA1. Don used the Prosoft
NDS Client for MacOS 5.12. He logged into NDS as prosoftuser.
Next, he used the Prosoft Netware volume mounter in the Chooser
to browse through NDS to the SRVR1's container and mount the
SRVR1_DATA1 volume via IPX. Even when prosoftuser has RWCEMFA
rights to DATA1, no Users folder is created by MacOS 9. However,
as soon as you use prosoftuser to do a bindery connection using
AppleShare in the Chooser, a Users folder gets created with the
Owner being [Supervisor] just as in the previous tests.
Test 4 [Netware 4.11, MacOS 9, Netware Client for MacOS 5.12, bindery connection using NW Client]
=================================================================================================
This test uses SRVR1, a Netware 4.11 server again. It also uses
MacOS 9 with multiple users and Prosoft's Netware Client for MacOS
5.12. For this test, make sure that there isn't a previous Users
folder on the server from previous testing. Log prosoftuser into
NDS using the Netware Client for MacOS 5.12. Next, use the Netware
volume mounter in the Chooser to mount DATA1 on SRVR1 using a
bindery connection. In this case, the Users folder did not get
created by MacOS 9 despite prosoftuser having RWCEMFA rights to
DATA1.
SOLUTION
The Users folder will not get created if a Users folder already
exists at the root the volume. Also, [Root] does not get added as
a trustee to a pre-existing Users folder. Thus the only step you
need to take to stop the MacOS 9 issue from affecting your server
is create a folder called Users at the root of every volume that
is accessible via AFP.