Coda File System

Re: Coda development (pioctl)

From: <u-x417_at_aetey.se>
Date: Fri, 30 Sep 2016 20:10:39 +0200
On Fri, Sep 30, 2016 at 12:40:08PM -0400, Jan Harkes wrote:
> If we already have to go through the trouble of creating a virtual file
> system, then I don't see the benefit of using rpc2.

I was thinking about the packing/unpacking of the data being moved.

This is a delicate matter (Kerberos e.g. had security-related bugs in
its ASN.1 many times and for a long time) so having just one place
where it is well debugged like rpc2 would be worthwhile.

> Also the numeric_uid numbers are not necessarily consistent between
> application, kernel, and venus processes so that probably wouldn't be a
> good thing anyway.

That's sad.

> good thing anyway. The reason for this is the continued push for
> restricted namespaces and other forms of containerization.

This is a development direction which does not look right to me.
Namespace isolation makes the access decisions per-namespace, not
per-object, which is far from flexible/complete.
I feel that by the isolation(s) the developers try to cover the faults
of the badly designed *nix access control with another non-general
design. Sigh.

> A long term benefit that I can see it that this replaces/surpasses the
> functionality of the PAG (process authentication group) in AFS. It
> allows the system to distinguish a user who logs into a machine over SSH
> from the same user logged in locally and can be used to prevent them
> from sharing the same Coda credentials.

I expect similar kinds of problems as with PAGs, but this is irrelevant.
We have to live on Linux with what it offers.

My only strong wish in relation to this, as a user/administrator, would
be for Coda itself not to depend on presense or use of namespacing.

> Since most ioctls are pretty simple in their purpose I think 90% or more
> should be about as hard as, or possibly easier than, getting the
> pioctlsecret file to work (getvolinfo, listcache, listlocal, getfid,...).

Hopefully the remaining 10% do not add too much weight :) but surely
I have nothing against a fully file-system-based pioctl replacement.

Pioctl in the kernel is kind of PITA, among others when considering
porting. Such a change in the user space would "directly improve the
kernel".

Thanks for the comments Jan and nice to see the new Coda and rpc2 release!

Regards,
Rune
Received on 2016-09-30 14:11:08