Vulnerability

    AFP

Affected

    MacOS 9 Multiple Users and Netware AFP

Description

    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.