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). >>> >>> > >
