[Afpfs-ng-devel] afpcmd

[<ra...@rs...>]

Alex,

On Tue, 17 Jun 2008 09:09:25 -0400, Alex deVries <ale...@gm...>
wrote:
> On 17-Jun-08, at 1:28 AM, Ralph Böhme wrote:
>> Am 16.06.2008 um 23:19 schrieb Alex deVries:
>>> The unix permissions situation in netatalk is a bit odd, and it is  
>>> likely true that afpcmd is broken in that it expects netatalk to  
>>> have unix permissions enabled.  I see this as a bug in netatalk,  
>>> but afpfs-ng should be able to handle a broken netatalk.
>>
>> Imo it's not a bug and it's not broken, it's just *different*.
> 
> It depends on what the objective of netatalk is, and there may be  
> different opinions on that.  I had thought that the objective was to  
> make an AFP server that would mimic Apple's AFP servers.  If that were  
> the case, then netatalk would provide unix privs for any AFP 3.x  
> connection.

Let me reitarate: imo netatalk indeed needs to change it's semantics,
that's why I am working on it. But: it need not only support upriv's by
default in most cases, it *must* also provide a mechanism which some call
"smart permissions" (Helios) others call "inherited permissions" (OS X).
Both are ways where the server happily advertises UNIX perms and silently
ignores any FPSetFil[Dir]Parms call to change mode.

Got the point?

I guess the netatalk folks haven't looked closely at what OS X afpd does
when serving a "inherited permissions" volumes and the semantics it uses.
So when you tell them "hell, you gotto use upriv per default", they do not
consider that it is possible to signalize and hand out UNIX privs, but
discard any attempt to change them, and therefore preserver the *very*
important semantics of privilege inheritence.
As said: I am working on it, still in early stages, so it's not time jet to
start discussing in on netatalk-devel. I will start that discussion within
a few weeks -- stay tuned... ;o)

Regards,
-Ralph