One trick I've used elsewhere is to have the canonical copy of the file
stored on disk space managed by a Linux guest and use the CMS NFS client
to create and update it. The trick then expects to create a small file
in a known location (/var/batch/files/tickets for this particular
instance) that contains the file location and the desired owner and
group information. I then have a small cron job that runs every 5
minutes and looks for the files in /var/batch/files/tickets, opens them
and does the appropriate chown/chgrp to make them visible to that user.
Since the Linux chown provides the SysV semantics that allow you to give
away ownership of files by username (rather than uid), the cron job can
be put into root's crontab and forgotten. 

The nice thing about this method is that it's fairly easy to plug a
Linux guest into any enterprise authentication method (LDAP, NIS, etc)
so you don't have to distribute userids and passwords at all, and you
get all the supported transfer methods they'd have elsewhere (SMB, scp,
ftp, etc, etc). 

You could probably reverse the idea by having the canonical copy reside
in a separate SFS filepool and having the Linux guest mount it as a NFS
filesystem. You could then punch a file to a service machine that
checked to see if the appropriate userid was enrolled in the special SFS
pool, and if not, enroll it and grant the appropriate ID access to the
file. Doesn't work as well as having the Linux system manage access
controls, but if the file is really huge, it's better than having
multiple copies. 

Reply via email to