James Carlson wrote: > > 957-966: this doesn't look right to me. I strongly suggest that you > contact the TX team ([EMAIL PROTECTED] or > [EMAIL PROTECTED]) to discuss the meaning of this > flag. Only MAC-aware applications ought to be setting this, and I > don't see where this code handles mandatory access controls at all. >
It's not as bad as it looks -- we are giving up the privilege rather than acquiring it. CIFS server actually does the same thing: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/smbsrv/smb_server.c#602 CIFS server had trouble with the following code segments: >From http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/inet/tcp/tcp.c#5773 5773 /* 5774 * If the caller has the process-wide flag set, then default to MAC 5775 * exempt mode. This allows read-down to unlabeled hosts. 5776 */ 5777 if (getpflags(NET_MAC_AWARE, credp) != 0) 5778 econnp->conn_mac_exempt = B_TRUE; Which if I recall correctly was causing problems binding to our service/accept socket here: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/inet/tcp/tcp.c#3579 3579 /* 3579 * If TCP_EXCLBIND is set for either the bound or 3580 * binding endpoint, the semantics of bind 3581 * is changed according to the following. 3582 * 3583 * spec = specified address (v4 or v6) 3584 * unspec = unspecified address (v4 or v6) 3585 * A = specified addresses are different for endpoints 3586 * 3587 * bound bind to allowed 3588 * ------------------------------------- 3589 * unspec unspec no 3590 * unspec spec no 3591 * spec unspec no 3592 * spec spec yes if A 3593 * 3594 * For labeled systems, SO_MAC_EXEMPT behaves the same 3595 * as TCP_EXCLBIND, except that zoneid is ignored. My understanding when I originally came up with this workaround (for the CIFS server code) was that since we were using a kernel thread we got the NET_MAC_AWARE privilege whether we wanted it or not. Typically a socket thread would come from user space and would not have this problem. The only components using sockfs from the kernel are iSCSI initiator (which doesn't call soaccept), CIFS server (which uses this workaround) and now our code. This is the sort of thing that makes me eagerly anticipate the volo project. I will solicit some input from rampart-dev-team. With the explanation above do you think its busted or is it just fishy? -Peter _______________________________________________ networking-discuss mailing list [email protected]
