At 5:33 PM -0500 7/2/99, Buck Huppmann wrote: >If kweiss doesn't belong to group cdlstaff, of course, then I'm a >fool for going off on this flight of pedantry, if not for using the >word pedantry Well kweiss certainly does belong to cdlstaff, so you're no fool on that account. But the process fsgid assigned by netatalk to the instance spawned for kweiss is not cdlstaff. So, as far as my limited understanding goes, the process shouldn't have write permission to the directory, because the process doesn't belong to cdlstaff (even though kweiss does). >From the ownership of /var/data/public/foo, it seems that kweiss (you?) >might belong to group cdlstaff. If that's the case, kweiss (or neta- >talk running as kweiss--same thing, almost) has permission to create >stuff in /var/data/public of whatever sort he wants to (almost), >with whatever permissions he wants; the file's group ownership is de- >termined by the kernel initially. In the case of Linux, ownership is >determined at creation time as spelled out in this excerpt from the >mount(8) man page (at least for ext2fs filesystems, and insofar as >this man page is up to date) >Since netatalk sets its effective uid to you and its gid to your primary >gid, it will create stuff owned by your primary group. If this isn't >what you want, you (or root) can set the setgid bit on your directories >(which is inherited by subdirectories created subsequent to such setting) > This all makes sense, and kweiss is a member of cdlstaff. However, when netatalk logs kweiss in, the GID assigned is 100, which is the default group in that passwd file, not the cdlstaff group. If I go to that directory at the Linux command line and attempt to write files, I get 'Permission denied' until I do a 'newgrp cdlstaff'. Then I can write files. That's exactly the behavior I expect. Netatalk appears to be able to write to any directory where I might conceivably have access as a group member, even if it is not the primary group that Netatalk obtains from the passwd file. I understand perfectly why the GID on the files netatalk creates match my default GID. That's the fsgid of the current process. However, that fsgid should not have permission to write into that directory. I don't understand why netatalk allows me to write into that directory in the first place, since my primary group does not have write permissions there. It seems like Netatalk automatically does a newgrp for every possible group I might belong to. As for using the word pedantry... :-) --Ken ------------------------------------------------------------------------- Ken Weiss [EMAIL PROTECTED] California Digital Library Technologies (510) 710-3356 (voice) UC Office of the President (510) 763-2471 (fax) 1111 Franklin Street #7313B [EMAIL PROTECTED] (text page) Oakland, CA 94607-5200 http://dcas.ucdavis.edu/kenhome.html
