I have a cgi script on a web server writing into an AFS directory with ACL rights wilk; i.e. "write" permission set minus the "r". The desired intent was to create a directory containing a file which the cgi script can append to, but would be unable to read from.
The above appeared to be working as I expected, until I started testing out
a replacement web server machine (having a different hostname, thus the httpd.hostname principal is different). Even when the ACL list in the
parent (and all ancestral) directories are the same for both instances,
the "wilk" permission set does not appear to be sufficient for appending
_UNLESS_ the principal also is the owner of the file (the old server owned
the files, and so worked without problem).
It is happy if it has the "r" permission added to the set, and does not even change the owner after appending. It also is happy if the owner of the file is changed and the "r" permission not added.
I have tested this out even with simple "echo 'AAA' >> file" type commands, so it does not appear to be an artifact of perl.
As AFS generally tends to be somewhat unconcerned about file ownership in most cases, this ownership dependency was unexpected. I searched some texts and the web on AFS ACL rights, and although only one explicitly mentioned "append" rights (http://www.engin.umich.edu/caen/technotes/afs.pdf) (stating that "w" permission sufficient for that), the more common definition of "w" as allowing modification of files content seems consistent with that.
Is this behavior "expected"? Am I missing something? Is there a way in AFS to have a file be append-only (possibly with creation if missing, but without being "readable") that does not depend on the principal appending to the file owning the file? _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info