In S10u6 labeled zones must use TCP sockets to connect to the global 
zone Xserver. The DISPLAY variable must be set to either 
global-zone-hostname:0 or localhost:0. Some code in X11 will fallback to 
using localhost:0 when :0 (specifying local transport, eg. UNIX domain 
sockets) fails. S10u5 and earlier don't support the use of localhost. 
When you use the Trusted Path to set workspace labels, the window system 
should automatically set up your initial DISPLAY variable correctly. 
However, if you just use zlogin, you have to take care of this yourself.

In OpenSolaris/Nevada, it is also possible to use UNIX domain sockets, 
but a bug in build 101 prevents this from working. It can be worked 
around with a manual LOFS mount in the global zone, but probably isn't 
worth the effort.


Mike John wrote:
> Bruno Gillet wrote:
>> Are you sure you have configured the unlabeled zone ?
>>  From a dtterm as root @ admin_high try to zlogin to your unlabeled
>> zone and press return. Don't you have some settings to complete ?
> No, "zlogin -C <labelled zone>" just gives a login prompt. The 
> experiment I mentioned with xclock was done using zlogin (without -C).
> This zone was, however, configured using a sysidcfg file, so I guess 
> there may be a problem there.
> Within the labelled zone, svc:/system/sysidtool:net, 
> svc:/system/sysidtool:system and 
> svc:/milestone/multi-user-server:default are all marked 'online', so it 
> seems healthy.
> The sysidcfg file also seems correct according to the documentation:
> name_service=NONE
> security_policy=NONE
> timeserver=localhost
> terminal=dtterm
> network_interface=vni0        { hostname=allzones
>       ip_address=
>       protocol_ipv6=no
>       netmask= }
> I've just found a couple of complaints in /var/log/sysidconfig.log 
> within the labelled zone:
> sysidconfig: Failure: Unable to determine terminal type
> sysidconfig: Failure: Duplicate Entry
> Perhaps I should recreate the zone from scratch, before pursuing this 
> any further.
> Thanks
> Mike
>> The X11 server is running admin_* so you should not have anything
>> to setup in your non global zones.
>> HTH,
>> Bruno.
>> Mike John a écrit :
>>> I have a system which is running TX on S10u6. It has a global zone and 
>>> just one labelled zone at the moment. For reasons we shan't go into, 
>>> Trusted CDE is the desktop of choice, rather than TJDS.
>>> I can happily log in as root and open dtterm windows within a CDE 
>>> session.
>>> There is another user configured and the clearance and label of that 
>>> user matches the label of the labelled zone. I can log in as that user 
>>> and get a desktop presented, but if I launch a terminal from the 
>>> workspace menu, the first attempt appear to do nothing, and the second 
>>> produces a pop-up saying "Action failed. Reconnect to Solaris Zone?"
>>> Looking at the log file generated by the labelled zone session, it 
>>> appears that the DISPLAY variable is being set to the host name 
>>> associated with the global zone primary interface, to which the 
>>> labelled zone has no routing.
>>> I have created an all-zones interface, and if I zlogin to the zone and 
>>> set DISPLAY to the host name associated with the all-zones interface, 
>>> xclock displays correctly. (Setting it to localhost appears to work 
>>> too - I notice that the loopback interface is now configured as 
>>> all-zones too.)
>>> If I set DISPLAY to the hostname of the global zone primary interface, 
>>> xclock fails to connect to the X server. (truss says that connect() on 
>>> a PF_INET6 socket fails with EHOSTUNREACH.)
>>> So it seems to me that I need to arrange for the DISPLAY variable to 
>>> be set to either localhost, or my explicitly created all-zones 
>>> interface, for CDE logins involving the labelled zone.
>>> Questions: am I on the right track, and if so how to achieve this? The 
>>> TX laptop instructions mentions /usr/dt/config/Xinitrc.tjds for TJDS. 
>>> Is there an equivalent for TCDE?
>>> Thanks
>>> Mike
>>> _______________________________________________
>>> security-discuss mailing list
> _______________________________________________
> security-discuss mailing list

zones-discuss mailing list

Reply via email to