Jan Harkes <jaharkes_at_cs.cmu.edu> writes:

> On Thu, May 05, 2016 at 02:09:36PM -0400, Jan Harkes wrote:
>> when creating a new volume' setting. It is actually hard to do this
>> right at the createvol_rep scripting level because setting acls requires
>> access to the volume through /coda, but right after creation the volume
>> isn't mounted anywhere, and the VRDB/VLDB databases may not even be
>> synced to all servers yet so even if we force a temporary mount the
>> mountpoint may not resolve right away.
>
> Aw, now I remember why we used to need the System:AnyUser ACL on the
> root of a new volume. Before realms, the /coda mountpoint would be the
> root directory of the first created volume. But to authenticate we
> clog needed access to /coda/.CONTROL, which was not possible without
> AnyUser access for unauthenticated users. So there was a bootstrapping
> chicken and egg issue when we didn't set that ACL by default.
>
> But because of realms, we don't have to care anymore because /coda is a
> directory invented by venus to show realm mountpoints that will allow
> access even to unauthenticated users.
>
> So we can safely remove the System:AnyUser default acl when creating a
> new volume root because the admin can always set it when he creates the
> new mount point.

That would help.

But my real problem is that I don't fully trust the coda security system
and wanted to wrap it with something that I could be confident on (plus
use the coda system).   I don't think there's anything malicious, just
that it's hard to get crypto protocols (and code) right, and N-S
implementations have had issues over the years.  Hence my bias toward K5
as something that's been shaken out.