[daip] Re: aipsuser group (fwd)

[Eric Greisen]

 > 
 > Now that's an interesting question.
 > 
 > Because we are installing AIPS in AFS rather than a traditional UNIX
 > filesystem, UNIX groups will *not* be relevant for access control.
 > Instead, we should grant write access to the required directories
 > through directory ACLs. We can do this after the fact, as long as
 > we know which directories are involved. Indeed we'll create a
 > group for this purpose, but it will be an AFS group, not a UNIX one.
 > 
 > Another issue is that I normally create multiple replicas of the AFS
 > volumes that contain software packages. This is both for performance and
 > for robustness against server failures. Whenever this is done, the
 > replicas most users will be working from are read-only. If we must
 > grant write access to some directories, we'll have to create separate,
 > non-replicated AFS volumes for them.
 > 
 > In any case, if we need to grant write access to only some files in a
 > directory, we'll have to replace them with symlinks to a separate,
 > writeable directory; this is because AFS access controls only work at
 > the directory level. We could make these symlinks point into an NFS
 > directory instead, in which case traditional UNIX filesystem semantics
 > apply (sort of; NFS isn't without its quirks).
 > 
 > Could you please find out:
 > (1) which system files need to be writeable (and if possible why);

       The area called $DA00 on each machine needs to be writable by
the users.  We put these directories as link files - say for my
machine primate - as

       $AIPS_ROOT/DA00/PRIMATE/

which is actually a link to a real file directory mounted on primate
called, e.g. /home/primate/AIPS/PRIMATE/ containing the files used by
the aips user.

       The aips user data areas of course must be completely writable
by the individual users.  I cannot think of a need to write other
areas and we block that here with no difficulty.

      Note that aips ZDAOPN.C which does all disk file opens attempts
a RW open and if that fails for access reasons then does a R only
open.  If the file is then written, it will fail.  This will then show
what is written.

The general areas called $FITS and $RUNFIL and $OFMFIL are empty when
aips is shipped and users should have write access to their copies of
those so they may read/write files there is they so choose (that is
optional).

 > (2) whether any of the AIPS scripts assume UNIX filesystem semantics
 > and explicitly check file GIDs in ways that AFS would break.

     The install.pl does check and chmod file privileges.  After that
I do not know of any - perhaps the MNJ (code in $UPDUNIX).

Eric Greisen

 > I'm copying this note to Lorant Sjouwerman (hoping he reads his
 > mailbox here @astro.su.se; I don't have his other address). Maybe
 > he can shed some light on this issue.
 > 
 > As a matter of policy, I don't want users to be able to interfere
 > with other users' work. Collaborate, yes; but denial-of-service
 > vulnerabilities must be plugged. If we can achieve that goal, then we
 > might as well grant write privilege to all our users: it will
 > simplify administration. So just use group astro for now.
 > 
 > Sergio
 > 
 > 
 >