CIFS client updates for auto-reconnect [PSARC/2009/366 FastTrack timeout 06/24/2009]

[Jordan Brown]

For the purposes of this case I don't care one way or the other - Darren 
asked for it, Gordon said OK.  However, I think there are interesting 
philosophical questions, so I'm continuing the discussion in private.  If 
anybody else is interested in joining in, just ask (privately).

Darren J Moffat wrote:
> Jordan Brown wrote:
>> For devices, I was under the impression that it was preferable to rely 
>> on file system permissions rather than having the driver do its own 
>> access control checks.  Should that precedent apply here?
> 
> Depends, but this isn't a driver it is a door server.
> 
> IMO door servers need to be as robust as possible - particularly if they 
> are running with any privilege but even if they are running as a 
> "normal" user.  Not only should they check who the peer caller is but 
> they also need to be very very careful about how they parse the input 
> coming over the door.  See the (unfortunately closed) source for kcfd as 
> an example.
> 
>> Darren J Moffat wrote:
>>> Gordon Ross wrote:
>>>>> Jordan Brown writes:
>>>>>>     Once running, smbiod accepts door calls asking it to make new
>>>>>>     connections.  Such door calls provide the server IP address
>>>>>>     and authentication information needed for initiating or
>>>>>>     re-creating a connection to a server.  Once the connection to
>>>>> What authorization or credentials are required for smbiod to accept a
>>>>> door call?  Does it just test UID?
>>>>
>>>> The door is owned by the user and has mode 0600.
>>>> That appears to be sufficient to prevent other
>>>> users from opening these doors.
>>>
>>> Given it is trivial to do so the door server should also check that 
>>> the calling peer is running with the same creds that it is.  See 
>>> door_ucred(3C) and ucred_get(3C).
>>>
>>>
> 
>