abruciamonti_at_bci.it said:
| Shortly, I need that a process belonging to "http" user can write on
| coda filesystem its own files with the proper http (unix) user
| permission's acls, without the need of authenticate the process http
| as Coda user.

| Is there a way to allow such unauthenticated system or user processes
| to write on Coda filesystem preserving Unix permissions, groups, ids,
| without even authenticating processes as Coda users?

Well, on our webserver, I've added the following lines to cronjobs that
need access to /coda

  # get a token
  echo $password$ | clog -pipe $username$ > /dev/null 2>&1

  <do usual stuff>

  # get rid of the token
  cunlog

For giving a long lived daemon access you could have only the clog line 
in a cronjob, and run the job once a day (and before the daemon is 
started).

I know, it is not nice having to put passwords in files, but it is
currently the way I solved this. The uid information of a file in Coda 
has a meaning of `who created this file' and not `who owns this file'.
Therefore, it is set the creator's token-uid (taken from the authenticated
connection). In fact only users in the System:Administrators group can
use chown to change a file's uid.

Access to files is regulated by the directory ACL's, so ownership, groups,
and filepermissions are not used by the Coda client or server to grant or
revoke access. There are however some cases where observed behavior is
currently not correct with respect to this picture.

Jan