On Sat, Sep 30, 2000 at 09:49:42PM -0400, Laszlo Vecsey wrote:
> I have a program that watches the local utmp file and if theres a change
> it copies it to /coda/system/hostname-utmp. So now all the other coda
> clients on the network can run 'who' on these utmp files to see people
> logged into other machines.
> 
> The problem as far I as can gather is that after some time period the
> file stops getting updated because the 'clog' token for the session of the
> program that copies the utmp's to /coda has expired. I think 24 hours.
> 
> Is there a way to for example create a small volume that just this
> specified user or program could write to, with no time limits?

Not really, it is the token that identifies that user or program,
without the token, neither the Coda client nor the server really knows
who is attempting to make the updates.

If you have compiled Coda yourself, there is the `tokentool' program in
coda-src/auth2/tokentool. This program allows you to create a token with
an arbitrary expiration time.

Because the token defines the used sessionkey this is not recommended
for general use, the `validity' of the token provides decreases over
time. But if the application is given limited access-permissions it
might work. Also because we do not have process authentication groups
(PAGs) you should probably run the program under a separate userid.

An interesting AFS/Coda feature, which at the moment is sadly broken is
the concept of the `virgin-store'. A virgin store is the first store
operation after creating a file so that an application with only insert
rights but no write ACL on the directory should be able to store data in
a file it has just created. It will probably require kernel changes to
get this to work again, but it would be useful having very limited
access-rights for daemons with tokens with a long expiration time.

Jan