Brian, You are right that a client doesn't get correct ucred of its connected peer when MLP is in use. I'll investigate why that's the case.
Thanks. Jarrett Brian Vetter wrote: > Jarrett, > > Rather than the pid, can you check to see if the proper ruid, euid > rgid, and egid are there. In my test, the pid information is correct. > But the ruid, euid, egid, and zoneid are all wrong (they are the > client's information). I have not checked the label and other peer info. > > Brian > > On Apr 7, 2008, at 2:50 PM, Jarrett Lu wrote: > >> Brian, >> >> I tried to reproduce what you described and observed the following: >> >> On server side (in global zone), I made port 6767 MLP: >> # zonename >> global >> # tninfo -m global >> private: >> 22/tcp;111/tcp;111/udp;513/tcp;514/tcp;515/tcp;2049/tcp;6000-6003/tcp >> shared: 515/tcp;6000-6003/tcp;6767/tcp >> # ./server >> in server... >> >> # pgrep server >> 193548 >> 193545 >> >> On client side, >> # zoneadm list -v >> ID NAME STATUS PATH >> BRAND IP 2 public running >> / native shared >> >> # ./client 129.146.108.64 >> server_pid = 193545 >> server_zoneid = 2 >> >> # pgrep server >> # >> >> As you can see from the above, getpeerucred() running in PUBLIC zone did >> get the correct pid of the server program running in GLOBAL zone. >> >> I also noticed that the zoneid field in ucred seems incorrect; it >> should be the >> global zone's id, 0. That may be a (different) bug. It may be a bug >> in base >> Solaris as I don't recall doing anything different for Trusted >> Extensions in >> this area. But I haven't verified that. >> >> The system was running an old onnv build (b73?). If you still think >> S10 has >> a bug, I can try it on S10 too. >> >> Thanks. >> >> Jarrett >> >> >> >> Brian Vetter wrote: >>> It is a connection between two processes in different or the same >>> zones on the same system using the virtual network interface (I >>> didn't try it on a shared loopback interface). If the port is a >>> multi-level port, the ucred information for the server is not passed >>> to the client. However, the reverse does work (the server can get >>> the ucred information of the client). >>> >>> I wrote a simple client and server test and it works perfectly when >>> the bound port of the connection is not a multi-level port. When it >>> is a multi-level port, the client can not retrieve the server's >>> credentials whether they are in the same zone or in different zones. >>> In this case, it returns the credentials of the client to the client >>> and not the server's credentials. >>> >>> Brian >>> >>> On Apr 4, 2008, at 7:05 PM, Jarrett Lu wrote: >>> >>>> Bill Sommerfeld wrote: >>>>> On Fri, 2008-04-04 at 16:29 -0700, Brian Vetter wrote: >>>>> >>>>>> Apparently, it only fails to work correctly when the connection >>>>>> is on >>>>>> an multi-level port. I've submitted a request to Sun since this >>>>>> is on >>>>>> Solaris 10. >>>>>> >>>>> >>>>> to be a little more specific, is this a connection over loopback >>>>> between >>>>> two processes in different zones/labels on the same system or is >>>>> this a >>>>> remote connection? >>>>> (this touches on some of the work I'm doing on labeled IPsec so I'm >>>>> curious about what you're trying to do). >>>>> >>>> >>>> This has to be between zones on a local system. I don't believe we >>>> can pass >>>> ucred info over remote systems. BTW, I wasn't aware MLP behaves >>>> differently >>>> in this regard. I'll test and confirm. >>>> >>>> Jarrett >>>> >>>>> >>>>> - Bill >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> networking-discuss mailing list >>>>> [email protected] >>>>> >>>> >>> >> > _______________________________________________ networking-discuss mailing list [email protected]
