u-myfx_at_aetey.se writes:

> On Wed, May 04, 2016 at 07:43:46PM -0400, Greg Troxel wrote:
>>   I am uncomfortable about the coda security scheme being a roll-your-own
>>   thing.  I would want to look at Kerberos or DTLS.  I realize this is
>>   harder than it sounds.
>
> Besides the token size, the security does not look bad.

Last I looked, there was the possibility of some fs data to travel
unencrypted if it was not associated with a logged-in user.  This is in
my view totally not ok.

> It is also an advantage, to be able to use Coda without a Kerberos
> infrastructure.

Sort of - I see it as Coda reimplementing something like Kerberos, so
you have to set that up instead.

>>   Whatever the next steps, IPv6 support is a big deal.
>
> I agree. OTOH this is not a showstopper yet.

It was a bigger deal for me, because I was using IPsec to avoid what I
perceived as security issues, and then I had NAT traversal issues.  But
I think we all agree it will become a bigger deal.

> As Jan commented and I agree, FUSE is unfortunately hardly viable.

I really do not understand how you can dismiss it as unviable. It seems
like Small Matter of Programming (not saying it's actually small) to
make venus talk to FUSE intead of the kernel module, to have venus
implement all the container file read/write, and to use magic paths for
control.  Do you really think that wouldn't work?

> A more general alternative would be not going through the kernel
> at all (like Christer Bernérus did in ULOCoda) - which unfortunately
> has its own limitations.

That just seems sort of like doing FUSE in libc instead of via FUSE.
It's a cool hack, but it expects too much of users (to do different
things, rather than running any program that works, even if it is an old
statically linked Linux binary with an old libc running on NetBSD under
emulation.

> There is another fully user space technology which could work well (use
> of Proot) but it exists only for Linux. Given the presence of the linux
> Coda kernel module we can as well continue to use the module.

Sure - the point of FUSE is that it's quite portable.  A Linux-only
solution doesn't really help.

>>   think it's perfectly ok if performance suffers a bit for this; working
>>   at 25% speed is 90% of the utility function for me, if not 95%.
>
> Sure, for portability I would certainly accept this.

Glad to hear it; there seems to be dogma about native-speed container
ops.   As I mentioned, glusterfs is running at nearly full GbE speed, so
it's unlikely to be a real problem.

>> despite having started in the 90s
>> and continued until 2015 some time.  The two reasons are having to run
>> IPsec to be comfortable with security and lack of portability.
>
> I hope you could find Coda attractive again when we improve security
> and possibly portability too. Which level of portability is crucial for
> you? To open platforms or to closed ones?

For me, what matters today is *BSD and OS X (several open and one
closed), and Android (which is sort of open and sort of closed,
depending on which version you run).  I haven't wanted to run it on
Linux or Illumos, but I think it's important that it work there.


Does Coda work on anything other than Linux and NetBSD today?