home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / unix / aix / 8844 < prev    next >
Encoding:
Text File  |  1992-08-15  |  3.1 KB  |  92 lines
  1. Path: sparky!uunet!cis.ohio-state.edu!ucbvax!bloom-beacon!bloom-picayune.mit.edu!news.mit.edu!probe
  2. From: probe@mit.edu (Richard Basch)
  3. Newsgroups: comp.unix.aix
  4. Subject: libs.a: group caching
  5. Message-ID: <PROBE.92Aug15233023@tardis.mit.edu>
  6. Date: 16 Aug 92 03:30:33 GMT
  7. Sender: news@athena.mit.edu (News system)
  8. Distribution: comp.unix.aix
  9. Organization: Massachusetts Institute of Technology
  10. Lines: 79
  11. Nntp-Posting-Host: tardis.mit.edu
  12.  
  13.  
  14. At MIT/Athena, we have a variant of the standard login program... it
  15. looks up the users from a central database and adds the user temporarily
  16. to the workstation's /etc/passwd file (and all the other files
  17. associated with the RISC/6000).  It also looks up the user's groups and
  18. adds those, also (primarily for the benefit of NFS).
  19.  
  20. What I have discovered is that adding a user using the calls:
  21.  
  22.     setuserdb(S_WRITE|S_READ);
  23.     setpwdb(S_WRITE|S_READ);
  24.     ...
  25.     putuserattr(...);
  26.     ...
  27.     putgroupattr(...);
  28.     ...
  29.     endpwdb();
  30.     enduserdb();
  31.     ...
  32.     setpcred(user,0);
  33.     setpenv(...);
  34.  
  35. does not properly initialize the user's grouplist... The user's
  36. grouplist will be a RANDOM subset of what is in /etc/group, even though
  37. the user appears to be in all of the groups according to /etc/group and
  38. the groups seem to be correctly listed in /etc/security/*.
  39.  
  40. I am assuming the internals of setpcred() are something like the
  41. following... I used something like the following in my own testing and
  42. found that the grouptoID() calls were failing even though all the
  43. various entries appeared to be in the files...  (Actually, my testing
  44. included some extra features such as eliminating duplicate gids, but
  45. I am not sure if the AIX internal routines do that, though it would be
  46. easy enough to test).
  47.  
  48.     char *group;
  49.     gid_t gid, gids[NGROUPS];
  50.     int groups=0, i;
  51.  
  52.     if (getuserattr(user, S_GROUPS, (void *)&group, SEC_LIST)==0) {
  53.         while (*group && groups<NGROUPS) {
  54.             if (grouptoID(group, &gid))
  55.                 gids[groups++] = gid;
  56.             while (*group++) ;
  57.         }
  58.         setgroups(groups,gids);
  59.     }
  60.  
  61. Anyway, after nm'ing the library and doing some more testing, I was
  62. guessing that various old data may have been cached by the library
  63. routines and not updated properly with putgroupattr() calls.
  64.  
  65. The only solution to the problem that I found was to use the following
  66. code prior to calling setpcred():
  67.  
  68.     /* Make sure there are no dangling references to userdb/pwdb */
  69.     i = chksessions();
  70.     while (i--) enduserdb();
  71.     i = chkpsessions();
  72.     while (i--) endpwdb();
  73.  
  74.     /* Clear cache of group entries */
  75.     endgroups();
  76.  
  77. Does anyone know what is going on, and if this is truly a bug... it
  78. appears to be a bug in 3.1.6 and 3.1.8.  I have not yet tested 3.2.
  79.  
  80. The only reason I do the multiple enduserdb()/endpwdb() is to ensure
  81. everything is properly flushed before doing endgroups().  The structure
  82. of our login program was such that the reference count on the
  83. userdb/pwdb was already 0, but I tend to have a paranoid programming
  84. style...
  85.  
  86. Also, am I using these routines correctly?  Obviously, I could refer to
  87. source code, but it seems like such a waste to taint myself if I can
  88. find out the information with "nm" and black-box testing.  I wouldn't
  89. need to use these routines if libs.a caching worked properly...
  90.  
  91. -Richard
  92.