Hi, > You don't have to send that really, the kernel will implicitly attach it > automatically whenever the sender's credentials change. Thus, a > receiver can safely assume that the ucred remains the same as the > SO_PEERCRED data until it receives a new SCM_CREDENTIALS that says > otherwise. > > You want to send SCM_CREDENTIALS explicitly only when you actively try > to impersonate someone else. I'm not convinced of that. Of course, sending the creds if it does not differ from the process running would be sufficient, but doing it in all cases removes a lot of complexity. Sending SCM_CREDENTIALS selectively would mean we would have to introduce a distinction between systemd-userdbd acting as multiplexer and not doing so, which would require moving quite a bit of code around that is now neatly generic. On the other hand, the only downside of always sending the credentials is a few bytes overhead on the wire. In my opinion, saving htese few bytes does not justify the added complexity by making a distinction between the code paths. What do you think? > In the varlink API please report the SCM_CREDENTIALS ucred seperately > from the SO_PEERCRED though (i.e. from the current ucreds we already > store). For various purposes it is interesting to know the identity of > the process initiating the connection, if it's different from the > process actually sending messages over it. Sure! Cheers, Nik
Attachment:
signature.asc
Description: PGP signature
