home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / protocol / appletal / 3189 < prev    next >
Encoding:
Text File  |  1992-08-25  |  1.9 KB  |  50 lines
  1. Newsgroups: comp.protocols.appletalk
  2. Path: sparky!uunet!cs.utexas.edu!torn!watserv2.uwaterloo.ca!watdragon.uwaterloo.ca!jmsellen
  3. From: jmsellen@watdragon.uwaterloo.ca
  4. Subject: cap60/aufs: permissions in drop folders question
  5. Message-ID: <BtK4vC.L02@watdragon.uwaterloo.ca>
  6. Organization: DCS Software Activists Squad
  7. Date: Tue, 25 Aug 1992 20:57:12 GMT
  8. Lines: 40
  9.  
  10. Given a directory that is mode 733, owner "A", group "1", an arbitrary
  11. user can use aufs to drop a file there.  With the current code, if the
  12. user is a member of group "1", then the file gets created mode 777.
  13. If the user is not a member of group "1", then the file gets created
  14. mode 733 (i.e. the same mode as the directory).  This means that the
  15. owner of the directory is unable to read the file, no one else can
  16. read the directory to discover the file is there, so it becomes just
  17. junk to be removed.
  18.  
  19. In applications/aufs/afpos.c there is this:
  20.  
  21.     private int
  22.     filemode(mode, uid, gid)
  23.     int mode, uid, gid;
  24.     {
  25.       int mo = mode & 0777;         /* convert st_mode to mode */
  26.       if (uid != usruid) {
  27.     /* check for conditions that would mean drop folder for us */
  28.     /* (but, don't accept a drop folder on basis of group that is */
  29.     /* world viewable even though it really is a drop folder for us) */
  30.     if ((mo & 04) == 0 && (mo & 040) == 0 && OSInGroup(gid))
  31.       mo |= 0666;               /* let everyone else read/write */
  32.     /* We need to do this because the poor person who get's the file */
  33.     /* can't do anything with it otherwise */
  34.       }
  35.       return(mo);
  36.     }
  37.  
  38. which is what determines the mode.  I think I think that the clause
  39.     && OSInGroup(gid)
  40. should be removed.  Perhaps if there is a group match, then the permissions
  41. for "other" should be curtailed?  Perhaps there should be a test for
  42. BSD group inheritence semantics, in which case the file gets created
  43. with the group of the directory anyway.
  44.  
  45. Opinions??
  46.  
  47. John Sellens
  48. University of Waterloo
  49. jmsellens@watdragon.uwaterloo.ca
  50.