Re: [zones-discuss] need help with zonecfg and networking
On Feb 8, 2012, at 5:13 PM, Will Fiveash wrote: > I used to be able to configure zones a while back but now I'm stumped > (using released S11). What I want is a set of zones, each with a unique > IP address such that they can ping each other and the global zone. I used to > use a zonecfg > of: > > create > set zonepath=/zone/newzone > set limitpriv="default,dtrace_proc,dtrace_user" > add net > set physical=nge0 > set address=10.0.0.2/8 > end > commit > exit If you want to do it this way you need to add set ip-type=shared since the default for the solaris brand is now exclusive. With exclusive you can't set the IP address this way. You need to use the anet resource instead. --Glenn > > and that did want I want. Now I see: > > n line 19 of /tmp/createzone.qEaOyF: > net: address cannot be specified if ip-type = exclusive > ip-type is set to 'exclusive' by default. > Zone master failed to verify > master: Invalid argument > > Note that in the global zone: > $ ifconfig -a > lo0: flags=2001000849 mtu 8232 > index 1 > inet 127.0.0.1 netmask ff00 > nge0: flags=1000843 mtu 1500 index 2 > inet 10.135.188.58 netmask fc00 broadcast 10.135.191.255 > nge0:1: flags=1000843 mtu 1500 index 2 > inet 10.0.0.1 netmask fc00 broadcast 10.0.3.255 > vboxnet0: flags=201000843 mtu 1500 > index 3 > inet 192.168.56.1 netmask ff00 broadcast 192.168.56.255 > lo0: flags=2002000849 mtu 8252 > index 1 > inet6 ::1/128 > > nge0:1 is the interface I use to get to the other zones. > > Any help is appreciated. > > -- > Will Fiveash > Oracle Solaris Software Engineer > http://opensolaris.org/os/project/kerberos/ > Sent using mutt, a sweet, text based e-mail app <http://www.mutt.org/> > ___ > zones-discuss mailing list > zones-discuss@opensolaris.org Glenn Faden | Senior Principal Software Engineer Phone: +1 408 276-6884 | Mobile: +1 415 637 8181 Oracle Solaris Security, Solaris Core OS Technology Engineering ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Zones in Trusted Extensions and Display Variables
On 4/28/11 12:25 PM, David Tarc wrote: What is the best practice for passing Display variables in labeled zones. I have heard about all-zones interfaces and unix domain sockets for passing the display variable. I however am finding it hard to find documentation on setting these configurations up. Any help would be helpful. It depends on what release of Solaris you are using. In Oracle Solaris 11 Express, unix domain sockets are used by default. That means that no networking configuration is required for labeled zones to connect to the multilevel destktop services running in the global zone. For Solaris 10 releases, you can share a single IP address (and the associated hostname) with all zones, using txzonemgr. This is known as an all-zones configuration. You can also just use DISPLAY=localhost:0 since lo0 is an all-zones interface. There are configuration instructions for various Solaris versions available for Solaris 10 and Oracle Solaris 11 Express on the OpenSolaris site: http://hub.opensolaris.org/bin/view/Community+Group+security/tx-laptop-install --Glenn Glenn Faden | Senior Principal Software Engineer Phone: +1 650 786 4003 | Mobile: +1 415 637 8181 Oracle Solaris Security, Solaris Core OS Technology Engineering ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Possible to use zones for hardening? Security?
Orvar Korvar wrote: I am still confused. "cjg" wrote at the very bottom, that it is possible to shutdown internet connection to the global zone and provided a link. I dont understand what the link says, as I am a Solaris noob. Can someone explain? I dont feel I have a definitive answer. Is it possible to shut down internet connection to the global zone, or not? And if it is possible, how do I do it? Just by "ifconfig e1000g0 down" or something similar? Yes. That is sufficient. --Glenn ORACLE ® Glenn Faden | Senior Principal Software Engineer Phone: +1 650 786 4003 | Mobile: +1 415 637 8181 Oracle Solaris Security, Solaris Core OS Technology Engineering ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Possible to use zones for hardening? Security?
VBox definitely works in zones. It installs a global zone SMF service, VBoxService, to take care of loading the kernel modules since this can't be done by a NGZ. see http://www.virtualbox.org/changeset/24240 --Glenn Jerry Kemp wrote: Ian, I believe that you are correct in your comment about running VirtualBox in a zone. Why I haven't attempted it myself, I believe that VirtualBox will not work from a zone because VirtualBox needs to load kernel modules. here is an example: ultra20 /root 401 # modinfo | grep -i vbox 175 f85127f0a88 345 1 vboxnet (VirtualBox NetAdp 3.1.4r57640) 177 f8682000 24de8 344 1 vboxdrv (VirtualBox HostDrv 3.1.4r57640) 250 f89e2000 6a20 346 1 vboxflt (VirtualBox NetDrv 3.1.4r57640) 250 f89e2000 6a20 - 1 vboxflt (VirtualBox NetMod 3.1.4r57640) 251 f89e9000 4598 347 1 vboxusbmon (VirtualBox USBMon 3.1.4r57640) 252 f89ee000 6de8 348 1 vboxusb (VirtualBox USB 3.1.4r57640) ultra20 /root 402 # uname -a SunOS ultra20 5.11 snv_130 i86pc i386 i86pc ultra20 /root 403 # Jerry On 09/30/10 15:55, Ian Collins wrote: I don't think you can install VirtualBox in a zone. If you are using VirtualBox, you can use the same networking tricks to get isolation as you would use for a zone. ___ zones-discuss mailing list zones-discuss@opensolaris.org -- ORACLE ® Glenn Faden | Senior Principal Software Engineer Phone: +1 650 786 4003 | Mobile: +1 415 637 8181 Oracle Solaris Security, Solaris Core OS Technology Engineering ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Possible to use zones for hardening? Security?
Assuming you're using the shared IP stack (default), it is sufficient for the global zone interface(s) to be plumbed so that the non-global zones can use logical instances of the interface(s). So setting the GZ interfaces as "down' will prevent network access to/from the global zone. --Glenn Jordan Vaughan wrote: Is there a way to disable all remote connections to the GZ? In other words, couldn't you use a firewall to reject connections on all ports to the GZ? That would effectively deny remote access to the GZ without having to disable any network interfaces. Of course, disabling the GZ's interface(s) is preferable (it's simpler), but I'm not sure if it's possible. I haven't tried it. Jordan On 09/29/10 10:33 AM, Orvar Korvar wrote: Ok, so it is impossible to shutdown internet connection to the global zone and surf only from the local zones. If I want to surf from the local zones, the global zone's NIC must be activated. I suspect a hacker will attack the global zone, instead of the local zone that I surf from. Are there any other ways to increase security instead of my original plan (shutting down the global zone and surf from local zones)? I am afraid the global zone will be attacked... ___ zones-discuss mailing list zones-discuss@opensolaris.org -- ORACLE ® Glenn Faden | Senior Principal Software Engineer Phone: +1 650 786 4003 | Mobile: +1 415 637 8181 Oracle Solaris Security, Solaris Core OS Technology Engineering ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zone with X
Florian Ermisch wrote: Well, how does this work with Trusted Zones? there you get gnome-workspaces which is connected to specific zones. wouldn't this be possible in a non-Trusted Zones environment, too? does someone know technical details? Trusted Extensions uses a single X11 server running in the global zone. The X clients running in non-global zones connect to the X11 server via an internal transport (loopback, vni, or UNIX domain sockets). A trusted path service running in the global zone acts like a GUI equivalent of zlogin, so that zone-aware application, like the GNOME panel, running in the global zone can launch X11 clients in the specific zone associated with the active GNOME workspace. Instead of running a standard X11 server in a zone, you should consider using Xvnc. --Glenn regards, Florian Am 27.07.10 12:32, schrieb Ben: Sorry about the wait. I've used this before: Shut down the zone From the global zone do this: pkg -R /path/to/zone/root install SUNWdbus Restart the zone This allowed me to do `SSH -X u...@myzone gedit` which might be halfway to what you want? HTH, Ben ___ zones-discuss mailing list zones-discuss@opensolaris.org -- Glenn Faden | Senior Principal Software Engineer Phone: +1 650 786 4003 | Mobile: +1 415 637 8181 Oracle Solaris Security, Solaris Core OS Technology Engineering ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zoneadm clone "-m copy" does not really "copy" on ZFS zonepath
Mike Gerdts wrote:
On Tue, Feb 16, 2010 at 9:08 AM, Christine Tran
wrote:
Does the data really need to be under the zonepath? If you were to do
something like:
zfs create -o mountpoint=/stuff rpool/stuff
mkdir /stuff/z1 /stuff/z2
zonecfg -z z1
add fs
set dir=/stuff
set special=/stuff/z1
set options=rw
end
exit
zonecfg -z z2
add fs
set dir=/stuff
set special=/stuff/z2
set options=rw
end
exit
Adjust paths as needed to fit your application. From the global zone,
you should be able to mv /stuff/z1/* /stuff/z2/* efficiently.
I think I have tried something like this, basically pre-make the
zonepath as directories before cloning the zone? It doesn't work. I
end up getting a new dataset mounted on the directory I've created.
What I am suggesting is that there is another file system that is lofs
mounted into each zone. Within z1 and z2 there are directories named
/stuff that really come from rpool/stuff/{z1,z2}.
Mike,
Your suggestion isn't suitable for Trusted Extensions because it
conflicts with the labeling policy for LOFS mounts. All such LOFS mounts
are forced to be read-only. Only the owning zone is permitted write
access, and the label reported for files under the mount point is the
label of the owning zone. In your workaround, the owner would be the
global zone. What Christine requires is that the files get properly
labeled and that they are mounted read-write.
The fact that the functionality changed from U5 in such a way that
prevents upgrading to U7 seems like a regression to me, and therefore is
a bug that must be fixed.
--Glenn
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] zoneadm clone "-m copy" does not really "copy" on ZFS zonepath
Christine Tran wrote: Hi, I'm sorry to bug the OpenSolaris for a question that pertains to S10U8, but I am really stuck. I am doing a zoneadm clone -m copy, and I do not want a new ZFS dataset even though my zonepath is on a ZFS filesystem, for performance reasons particular to how I am using my zones. Unfortunately, zoneadm clone just ignores the "-m copy", and makes me a new ZFS filesystem anyway; and by the speed with which it finished, it certainly is a snapshot operation underneath. I have tested with making the source zone on a separate UFS, have pre-made a dirname under my ZFS filesystem as the zonepath, nothing works. I always get a new ZFS filesystem. I see that zoneadm install has an -x nodataset switch, I need this for zone clone as well. I have not seen this filed as a bug against S10, is there a work-around to get the behavior I want? I understand your dependency on having all your zones sharing the same dataset. From a quick look at the code it seems to me that your specifying -m copy is supposed to force a copy rather than a clone. if (method == NULL && is_zonepath_zfs(source_zonepath)) err = clone_zfs(source_zone, source_zonepath, zonepath); if (err != Z_OK) err = clone_copy(source_zonepath, zonepath); Since you're not getting this behavior, it may be a bug. However, you should also be aware that the -m copy functionality is not currently implemented in OpenSolaris. So this will be a problem for you in future, too. What you really need is the ability to do a move or rename between datasets in the same zpool. There is an open RFE that I submitted about this issue when TX was first integrated. Maybe you can provide a business case why it should be escalated. 6483179 Provide an efficient way to rename a file to another dataset in same zpool --Glenn This is sort of a big deal for our application. We use labeled zones, a file move within a filesystem has a different performance profile than a move from one filesystem to another filesystem, even within one ZFS pool. We are doing tens of thousands of move per minute. CT ___ zones-discuss mailing list zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Shareing files between zones
Mike Gerdts wrote: A non-global zone cannot be an NFS server (without a third-party userland NFS server implementation). Also, NFS mounting a file system in a non-global zone that is exported from that zone's global zone is not supported. It may seem to work, but there is a known deadlock that can happen. This known deadlock is documented as a UFS/NFS/VM issue. It's never been clearly stated that it applies when using ZFS and NFS. I've been exporting ZFS home directories from the global zone into my non-global zones for years. I've never experienced the deadlock, but my systems are single-user laptops, so that may not create enough contention. --Glenn ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Configure a zone through sysidcfg
Jordan Vaughan wrote:
On 08/14/09 02:55 PM, v wrote:
I created an exclusive IP zone. Now I want to configure it using
sysidcfg and avoid the prompts at the initial login.
I created the below sysidcfg file:
timezone=US/Eastern
system_locale=C
terminal=xterms
network_interface=vnic1 {dhcp protocol_ipv6=yes}
root_password=abc123
security_policy=none
name_service=DNS nfs4_domain=dynamic
I wanted to copy this file to the zone's etc directory, but there is
no such directory at this time (I already installed and booted the
zone). I go to /export/zones/zone1/root but the directory is
empty. There is nothing in there. There is no .../zone1/etc
either. So, I created an etc directory under root directory, put my
sysidcfg file, and logged into the zone. I still got the initial
configuration prompts. Apparently, it didn't looked at the sysidcfg
file. What I am doing wrong?
Thanks...
How can a zone's root directory be empty after the zone is installed
and booted?
Starting in OpenSolaris 2009.06 the zone's root filesystem is unmounted
when the zone is not active (being installed, ready, or booted). So if
you try to place a sysidcfg file in the zone's /etc directory after the
installation is completed, you will see that the directory doesn't
exist. A workaround which we use in Trusted Extensions is to do
something like this:
# zoneadm -z public install
# zoneadm -z public ready
# cp sysidcfg /zone/public/root/etc/sysidcfg
# zoneadm -z public boot
--Glenn
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] Problem booting previous working zones after reboot.
maco wrote: Glenn, Thanks for the quick reply. I installed OpenSolaris 2008.11, but have kept it up to date with the package manager. The only mounted ROOT filsystem is the main one mounted on /. I've since tried to make the zone ready with: r...@gaia:/zones# zoneadm -z poseidon ready zoneadm: zone 'poseidon': call to zoneadmd failed I've also tried creating a new zone (test) to see if it's just existing zones that are affected, but the install command is failing: r...@gaia:/zones# zoneadm -z test install A ZFS file system has been created for this zone. ERROR: Unable to create the zone's ZFS dataset. The above error comes from the script /usr/lib/brand/ipkg/pkgcreatezone. The zfs create at line 230 is apparently failing. It would be useful to see the output of the following command: # zfs list|grep zones to see if the zone ROOT dataset exists. --Glenn ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Problem booting previous working zones after reboot.
Maco,
Are you running OpenSolaris 2009.06? A difference in this release is
that each zone's root filesystem is unmounted when the zone is halted
and then remounted when the zone is booted. If the unmount fails on
halt, then the subsequent mount on boot fails because it's already
mounted. The error message in this case matches what you're reporting.
To confirm that you are experiencing this problem (on 2009.06) try
running this command in the global zone:
# mount -p|grep ROOT
If you see entries like this:
rpool/zones/public/ROOT/zbe - /zone/public/root zfs ...
and the zone name, e.g. public is not ready or running, the unmount
apparently failed. You can probably do a forced unmount as a workaround,
e.g.:
# umount -f /zone/public/root
to clear the problem.
--Glenn
maco wrote:
Hiya all, hopefully you might be able to shed some light on a zones problem
that I've got. I think this is the correct forum to post to, as I've got
OpenSolaris installed and working. If not, please let me know and I'll repost
to the correct forum!
---
I've got several zones installed and (until recently) all running correctly
with no problems. I've had to reboot the machine and since then, none of the
zones are able to boot. The only error message I'm getting is:
r...@gaia:~# zoneadm -z poseidon boot
zoneadm: zone 'poseidon': call to zoneadmd failed
I've tried restarting the zones:default service with svcadm, it starts
correctly, shows as 'online' with svcs. The log file is saying:
[ Aug 12 21:24:59 Enabled. ]
[ Aug 12 21:24:59 Executing start method ("/lib/svc/method/svc-zones start").
]
Booting zones: poseidon apollo athena hades zeus
zoneadm: zone 'hades': call to zoneadmd failed
zoneadm: zone 'athena': call to zoneadmd failed
zoneadm: zone 'poseidon': call to zoneadmd failed
zoneadm: zone 'zeus': call to zoneadmd failed
zoneadm: zone 'apollo': call to zoneadmd failed
.
[ Aug 12 21:25:01 Method "start" exited with status 0. ]
I've tried google, but the errors others are getting are more specific (i.e.
filesystem/vnic errors), but I can't see a simple solution.
I've only recently started using OpenSolaris, so I'm lacking in experience as
to where to look now that the log files have been equally vague! Any pointers
to where to look for additional information, or an idea of what's gone wrong
would be greatly appreciated.
Thanks for your time!
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] Forcing all FS traffic into a global zone
Roman V Shaposhnik wrote: On Tue, 2009-06-30 at 17:00 -0500, Nicolas Williams wrote: The problem at hand is a reentrance issue in the VM. Could you, please, point me to the most authoritative CR that captures this issue? Hasn't it been mentioned in this thread already? I could search for it, but so could you -- I wouldn't know if off the top of my head any more than you would. The only one that floated by was: 5065254. To tell you the truth -- it looks cryptic. Hence my request for the CR that captures the essence of the issue, not just a manifestation. Thanks, Roman. Yes, that's one of them, but this has a long history going back to 2001. 4498652 deadlock between ufs and nfs 4956821 nfs*_mount should prevent local mounts A more recent and relevant bug is: 6811806 automounter should prevent zone-to-global-zone mounts --Glenn ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Parallel mount question
Roman V Shaposhnik wrote: On Tue, 2009-06-30 at 12:58 -0700, Glenn Faden wrote: This should be added to the FAQ ! As already said by others, it's not perfect, as it should be set up in the global zone, but it's really better, better, better, better than the current answer. Doesn't work. That's what I thought too. The question though is -- why not *let* it work under explicit permission? Again, I understand the use case why it shouldn't work. But why there's no acknoledgement of a usability of a case where it makes sense. Doesn't a glance at this thread provide enough of a conviction that asking a global zone to route *all* FS related traffic is a useful thing to do? My personal question now is : why didn't I find it by myself ! :-) Because it doesn't work. See: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/autofs/auto_vnops.c#auto_trigger_mount 1403 /* 1404 * Cross-zone mount triggering is disallowed. 1405 */ 1406 if (fnip->fi_zoneid != getzoneid()) 1407 return (EPERM);/* Not owner of mount */ This place is easy to fix if you ask me. The real question is what kind of long lasting impact would allowing such a thing have. And this is a conversation I'm very interested in having. If this were easy it would have fixed already. I think the following is what we really need: 1. Allow non-global zones to be NFS servers 2. Allow automounting between zones I had also tried (and failed) to implement a new kind of automap similar to the existing entry /net -hosts but using zone names instead of hostnames: /zone -zones I implemented this for Trusted Extensions in 2005 but couldn't fix the zone and automounter deadlocks, so it never go putback to OpenSolaris. --Glenn ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Parallel mount question
Nicolas Dorfsman wrote: Le 30 juin 09 à 16:13, Moore, Joe a écrit : William Roche wrote: Now about the automounter, I share Nico's point of view, but as far as I know nothing like that already exist, and No, the automounter or a mount request isn't 'clever' enough (or customized enough) yet to handle NFS data shared by the global zone and translate the mount request into an LOFS mount. So be careful with NFS share from the global zone when you have local zones on the same machine. The global zone could be the one running automount. Since it knows what host is "local", it'll convert the nfs mounts to lofs automagically. For each zone, add the zone's automount entries to global:/etc/auto_master as /zonepath/root/home +auto_home vers=3,nosuid (for example) Excellent ! Sorry... This should be added to the FAQ ! As already said by others, it's not perfect, as it should be set up in the global zone, but it's really better, better, better, better than the current answer. Doesn't work. My personal question now is : why didn't I find it by myself ! :-) Because it doesn't work. See: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/autofs/auto_vnops.c#auto_trigger_mount 1403 /* 1404 * Cross-zone mount triggering is disallowed. 1405 */ 1406 if (fnip->fi_zoneid != getzoneid()) 1407 return (EPERM);/* Not owner of mount */ --Glenn ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Parallel mount question
Moore, Joe wrote: William Roche wrote: Now about the automounter, I share Nico's point of view, but as far as I know nothing like that already exist, and No, the automounter or a mount request isn't 'clever' enough (or customized enough) yet to handle NFS data shared by the global zone and translate the mount request into an LOFS mount. So be careful with NFS share from the global zone when you have local zones on the same machine. The global zone could be the one running automount. Since it knows what host is "local", it'll convert the nfs mounts to lofs automagically. Yes, that part works. For each zone, add the zone's automount entries to global:/etc/auto_master as /zonepath/root/home +auto_home vers=3,nosuid (for example) Haven't tried it. It would muck up NFSv4 identities, and blur the lines between the global zone administrator and a local zone admin. I've tried this over the years. It doesn't work for several reasons. In particular, there is a check in the kernel autofs code to prevent it. But even if that was changed there would need to be some synchronization to inform the global zone automounter about the state of the zones so that the autofs trigger mounts could be managed properly. --Glenn ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Parallel mount question
James Carlson wrote: On Jun 29, 2009, at 2:31 PM, Glenn Faden wrote: Steve Lawrence wrote: I think each zone's automounter is smart enough to use lofs instead of nfs for mounts from a non-global to a global zone. Please explain how this is possible. How can the automounter convert an nfs specification of a global zone pathname into a pathname which can be expressed using the non-global zone's lofs semantics? It'd have to be a helper out in the global zone that sets up the correct lofs mount. Jim, You may remember that during the early days of the Trusted Extensions project I tried to get the global zone automounter to act as such a helper process. This was before the automounter used doors, and I couldn't get the TLI code to work across zones reliably. There were synchronization issues since the global zone automounter wasn't aware of individual zone states. Maybe a better helper program might be the zoneadmd process that is associated with each zone. --Glenn ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Parallel mount question
Nicolas Williams wrote: On Mon, Jun 29, 2009 at 11:31:20AM -0700, Glenn Faden wrote: Steve Lawrence wrote: I think each zone's automounter is smart enough to use lofs instead of nfs for mounts from a non-global to a global zone. Please explain how this is possible. How can the automounter convert an nfs specification of a global zone pathname into a pathname which can be expressed using the non-global zone's lofs semantics? Well, it doesn't have to be possible. Instead it should be possible to have the mount(2) syscall detect the loopback NFS and convert it into a lofs mount if, say, a flag is set in the arguments, or even by default. I've thought about doing this in the past, but wasn't sure that it would work. The automounter is has some special processing for NFS, and I don't know what would happen if a requested NFS mount got turned into sa LOFS mount. For example, the automounter attempts to unmount anything it mounted that is no longer busy. So, it might also be necessary to modify the umount syscall to translate NFS umounts to LOFS umounts. Then there is the issue of the automounter looking up entries in /etc/mnttab. It might get confused when looking for NFS entries that were turned into LOFS. That would work transparently for the automounter. Though it the automounter were not calling mount(2) directly, but instead passing back mount info to the autofs kernel module caller (which it does for some fs types), then the autofs module would need to know how to convert the mount to a lofs mount. Note that cross-zone LOFS mounts have a fictitious value for "special" when viewed in the zone's /etc/mnttab. Instead of the actaul global zone pathname, the special is represented as a duplicate of the zone-relative mountpoint. So it's not obvious how the automounter can do a useful conversion. For this to work, the kernel would have to internally do a LOFS mount but somehow make it appear externally that it is an NFS mount. --Glenn ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Parallel mount question
Steve Lawrence wrote: I think each zone's automounter is smart enough to use lofs instead of nfs for mounts from a non-global to a global zone. Please explain how this is possible. How can the automounter convert an nfs specification of a global zone pathname into a pathname which can be expressed using the non-global zone's lofs semantics? --Glenn ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Can you plese let me know whether OpenSolaris 2009.6 support sparse zonnes?
Edward Pilatowicz wrote: the "inherit-pkg-dir" property is only applicable to solaris distros which use SVR4 packaging. (this means solaris 10 and SXCE). it is not applicable to opensolaris system. using it on opensolaris based systems will result in undefined behaviors and unsupporable configurations. we actually have a bug filed on this issue: 567 ipkg zones verify callback should abort if it sees inherit-pkg-dir http://defect.opensolaris.org/bz/show_bug.cgi?id=8567 the fix for this bug will verify that ipkg brand zone configurations don't have any inherit-pkg-dir properties, and if they do the configuration will be reported as invalid. The labeled brand used by Trusted Extensions in opensolaris is still using the inherit-pkg-dir property, but this is described in bugzilla 9191 labeled zones should no longer rely on sparse-root functionality and a fix will soon be putback to the /dev repository for 2009.06. Since the labeled brand shares much of its configuration with the ipkg brand, bugzilla 567 should be integrated after 9191. --Glenn ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Update Grants, Merge BrandZ and Zones Communities
I would like to nominate myself as a Core Contributor, having
implemented several zones features (labeled zones, defrouter, cross-zone
FIFOs, etc.). FYI, Trusted Extensions is also using branded zones at
this time and has an active case to for a new brand called "labeled". I
am currently a Core Contributor in the Security Community, and active in
the Zones community,
--Glenn
Dan Price wrote:
(Credit to Alan Coopersmith and Liane-- from whom I've cribbed some of this)
OGB election season is approaching again, so it's time to begin our annual
review of Contributor & Core Contributor grants for the Zones community.
See "BACKGROUND" below for more background on this process.
At this time I would also like to propose that we merge the BrandZ and
Zones communities. These two activities are interrelated, and it's
easiest if I start with the merger first.
1. PROPOSED BRANDZ COMMUNITY MERGER
All contributor grants for the BrandZ community are due to expire this month.
I would like to propose the merger of the BrandZ community into the Zones
community at this time. This is in some ways reflective of the work done
in the past two years by Jerry Jelinek to broaden the scope of the BrandZ
infrastructure. Today, all zones are branded (even "native" ones). And
the same team now owns the charter for both technologies.
Having spoken to several of the core contributors of the zones community,
the BrandZ community, and to an OGB member, I am at this time recommending
that we utilize article 7.12 ("Termination", see below) of the OpenSolaris
Constitution, and allow all of the contributor grants in the BrandZ
community to expire. This will terminate the community.
The communities will forward to the OGB their recommendation that, under
article 7.12, the BrandZ community's contents should be merged with the
Zones community. We will ensure that web content related to BrandZ is not
lost, and the brandz-discuss mailing list will continue on. That is to
say, except for less bureaucratic overhead, everything will be the same as
before. The zones community will take extend sponsorship to all projects
sponsored by the BrandZ community. No specific changes to the "project"
structure are proposed here, only a reparenting.
For reference, article 7.12 states:
7.12. Termination. A Community Group is terminated by act of
the OGB or by reduction of its named Core Contributors to a
number less than three (3). Upon termination, the OGB may
re-initiate the Community Group with a new set of Core
Contributors or reassign the resources that were assigned to
the Community Group, such as mailing lists, forums, and website
information, to the at-large community or to some other
Community Group of the OGB's choosing.
(http://opensolaris.org/os/community/ogb/governance)
2. PROPOSED GRANTS
The current grants for the zones and BrandZ communities are as follows.
All grants are due to expire this month.
login name StatusCommunity
-
allan Allan McKillopcore contrib zones
annt Ann Togasaki core contrib zones
dp Daniel Price core contrib zones
comay David Comay core contrib zones
gjelinek Jerry Jelinek core contrib zones
mgerdtsMike Gerdts core contrib zones
stevelaw Steve Lawrencecore contrib zones
jeffv Jeff Victor contributor zones
pcottenPenelope Cotten contributor zones
richlowe Richard Lowe contributor zones
edpEdward Pilatowicz core contrib brandz
nilsn Nils Nieuwejaar core contrib brandz
rabRussell Blainecore contrib brandz
kucharsk William Kucharski core contrib brandz
ahlAdam H. Leventhal contributor brandz
jcmJerri-Ann Meyer contributor brandz
hannkenJurgen Hannken-Illj contrib.brandz
kirk Kirk Wellscontributor brandz
Based on recent contributions, I would like to propose the following
for the resultant merged community. This is a *proposal*. I would like
input:
login name StatusReason
comay David Comay Emeritus former zones team lead, former CC
dp Daniel Price Core Contrib Renew, still active
gjelinek Jerry Jelinek Core Contrib Renew, still active
stevelaw Steve LawrenceCore Contrib Renew, still active
jeffv Jeff Victor Core Contrib Upgrade, Zones FAQ, Advocacy
pcottenPenelope Cotten Core Contrib Upgrade, Docs author, Zones FAQ
edpEd Pilatowicz Core Contrib New, Code cont, BrandZ core contrib
flippedb Jordan VaughanCore Contrib New, Code contributions
richlowe Richard Lowe Contributor Renew
menno Menno Lageman Contributor New, Code contrib, work on Rsrc m
Re: [zones-discuss] Install zones, configure as DHCP client
Arun, When running OpenSolaris as a VirtualBox guest, the DHCP service is provided by the VirtualBox process. I don't know if VirtualBox will respond to requests from multiple guest NICs if your host only has one active NIC. If it does, then you should be able to follow this procedure described in Steffen Weiberle's blog: http://blogs.sun.com/stw/entry/crossbow_is_delivered_traveling_vnics Anyway, this seems to be more of a question about VirtualBox networking, than zones. --Glenn Arun Gupta wrote: > Hi Bill, > > That might be it and I'm new to all this :) > > End goal: Configure 2 non-global zones in a Open Solaris Virtual Box > image and assign them addresses using DHCP server running in Global zone. > > What exact command would serve that purpose ? > > -Arun > > Bill Walker wrote: > >> Maybe I am missing something here, but wouldn't it be easier to do that >> kind of thing with zonecfg? Unless you are changing some other settings >> other than the IP... Just trying to understand the end result you are >> looking for. >> >> bill. >> >> >> Arun Gupta wrote: >> >>> I'm looking for simple instructions to install zones, configure them >>> as DHCP clients to the DHCP server in global zone (all in an >>> OpenSolaris VM using Virtual Bx). The documentation at >>> http://docs.sun.com/app/docs/doc/817-1592/ seems to quite involving >>> and keeps referring to multiple pointers instead of providing >>> consolidated docs. >>> >>> Are these instructions available any where ? >>> > > ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] lupi_zones core dumping
Wayne, I don't think your problem is related to 6208468 since it works when invoked from a command line. If the program /etc/lib/lu/lupi_zones is failing when invoked by Java, it must have something to do with the environment, like controlling tty or open file descriptors. Is there a core file? --Glenn Wayne Nichols wrote: > Having a very strange problem here. Looks related to this one: > > http://bugs.opensolaris.org/view_bug.do;jsessionid=1c7c4c7edd00e5b5f4a7c60f1cc4?bug_id=6208458 > > But here's a little bit of background: > > Have a perl script that calls a shell script to build a zone. shell > script of course has a line "zoneadm -z zonename install" > When the perl script is run manually, from the command line, I have > never seen a problem. But, when it is called from a java exec I get: > > genunix: NOTICE: core_log: lupi_zones[22424] core dumped: > /var/core/core_testnoflar_lupi_zones_0_60003_1232079570_22424 > > as a result of the zoneadm install command. > > Ultimately I need this to be called from a JVM, but I am running into > this problem. It could well be a JAVA problem, but don't know where > to start for help. > > I'm running S10 TX U5, minimized OS. > > bash-3.00# java -version > java version "1.6.0_06" > Java(TM) SE Runtime Environment (build 1.6.0_06-b02) > Java HotSpot(TM) Server VM (build 10.0-b22, mixed mode) > > Hardware: T5220/T5140 > > I can't seem to get anything on the related bugs. > > Any insight appreciated. > > Wayne > > > ___ > zones-discuss mailing list > zones-discuss@opensolaris.org > ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Setting of DISPLAY for Trusted Extensions labelled CDE sessions
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.
--Glenn
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 " 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=10.1.0.1
> protocol_ipv6=no
> netmask=255.255.0.0 }
>
> 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-disc...@opensolaris.org
>>>
>
> ___
> security-discuss mailing list
> security-disc...@opensolaris.org
>
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] Package minimization question
Christine, From the package list I assume you are running Solaris 10, not OpenSolaris. I suppose you can leave out the X11-related packages, but it isn't a valid assumption that a headless system doesn't need these packages. X11 applications can be remotely displayed using X protocol, or via Xvnc to a system with a framebuffer. Since you state that other systems you've built have worked so far, I guess you've got your answer. --Glenn Christine Tran wrote: > Cross-posted, pardon me for duplicates. > > I'm building a system starting with SUNWCrnet, it needs zones and TX. > Using the fine Solaris Package Companion tool, I'm down to the > following: > > [C] SUNWCzoneXXSolaris Zones > [P] SUNWzoner PASSEDSolaris Zones (Root) > [P] SUNWzoneu XXSolaris Zones (Usr) >x [P] SUNWadmfrSystem & Network Administration > Framework Configuration >x [P] SUNWadmfwSystem & Network Administration Framework >x [P] SUNWctplsPortable layout services for Complex > Text Layout support >x [P] SUNWdtcorSolaris Desktop /usr/dt filesystem anchor >x [P] SUNWj5rt JDK 5.0 Runtime Env. (1.5.0_14) >x [P] SUNWmfrunMotif RunTime Kit >x [P] SUNWpool Resource Pools >x [P] SUNWpoolrResource Pools (Root) >x [P] SUNWxwdv X Windows System Window Drivers >x [P] SUNWxwfntX Window System platform required fonts >x [P] SUNWxwiceX Window System Inter-Client Exchange > (ICE) Components >x [P] SUNWxwplrX Window System platform software configuration >x [P] SUNWxwpltX Window System platform software >x [P] SUNWxwrtlX Window System & Graphics Runtime > Library Links in /usr > /lib > > > [C] SUNWCts XXSolaris Trusted Extensions > [P] SUNWtsgXXTrusted Extensions global > [P] SUNWtsuXXTrusted Extensions, (Usr) > [P] SUNWtsrXXTrusted Extensions, (Root) >x [P] SUNWctplsPortable layout services for Complex > Text Layout support >x [P] SUNWdtbasCDE application basic runtime environment >x [P] SUNWdtcorSolaris Desktop /usr/dt filesystem anchor >x [P] SUNWmfrunMotif RunTime Kit >x [P] SUNWxwcftX Window System common (not required) fonts >x [P] SUNWxwdv X Windows System Window Drivers >x [P] SUNWxwfntX Window System platform required fonts >x [P] SUNWxwiceX Window System Inter-Client Exchange > (ICE) Components >x [P] SUNWxwoptX Window System Optional Clients >x [P] SUNWxwplrX Window System platform software configuration >x [P] SUNWxwpltX Window System platform software >x [P] SUNWxwrtlX Window System & Graphics Runtime > Library Links in /usr > /lib > > The x indicates missing packages not in SUNWCrnet. > > I wonder if the X Window, Motif, CDE and Text Layout is *really* > necessary. I don't have a problem adding pools and the two admin > packages. Other boxes built without these packages have worked fine > so far. However, eventually they will need support, and I don't want > to be in that place where I have to explain why a headless box that > runs no graphics needs X, and un-supportability. > > Thanks! > > CT > ___ > security-discuss mailing list > security-disc...@opensolaris.org > ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] shared IP with defrouter .VS. exclusive IP
fu qilai wrote: > Hi,Can I defrouter my non-global zone to match exclusive IP model for Solaris > 10 10/08? > > [Feature:The ability to set the default router through an optional defrouter > property in a shared-IP zone added. ] > > > (1)A machine connects to LAN1 via NIC1 and LAN2 via NIC2 . (VLAN) > > (2)Global zone connects to LAN1 with proper address configured on NIC1, >gateway is assigned to an address on LAN1 > NIC2 is in unplumb state with no address configured > I think NIC2 will have to plumbed in the global zone in order for a logical instance to be created for use by the non-global zone. However, NIC2 can be down in the global zone. --Glenn > (3)in non-global zone with share IP model, add NIC2 with address configured >and connects to LAN2,gateway is assigned to an address on LAN2, >does not add NIC1 at all. > > (4)So,non-global zone could access LAN2 nodes but could not access global zone >directly(because it's on LAN1)? >non-global zone could only access other node outside LAN2 via its default >gateway(LAN2 address assigned by defroute)? > ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Shared-ip zones with defrouter
Steffen, The defrouter feature doesn't change any existing kernel functionality. It simply automates setting up routes which could have been established by the global zone administrator. Whether those routes are useful depends on factors beyond the zone configuration. --Glenn Steffen Weiberle wrote: > On 10/06/08 21:38, Glenn Faden wrote: > >> Max, >> >> The default route option is not specific to TX zones. However, it is >> intended for environments where your zones aren't sharing the same >> physical interfaces. This feature sets the default route for an >> interface so I don't think it will provide the functionality you are >> looking for. >> >> --Glenn >> > > Hi Glenn, > > The preliminary documents say the same thing, that the 'defrouter' is > for the interface. > > I see an opportunity to clarify the behavior as my initial expectation > was that since the defrouter attribute is set in a zone's configuration, > it applies to the zone. > > What happens when multiple zone configurations have different defrouter > definitions for the same interface or the same subnet (given the > complexity should multiple subnets be configured on a single interface)? > > Thanks > Steffen > > >> Max Levine wrote: >> >>> Hi, >>> >>> We have a need to define a separate defaultroute for some of the >>> shared-ip zones in our environment. All of the zones are on the same >>> subnet, but only some need to have a different default route. I was >>> reading psarc/2008/057 but I am confused if the functionality applies >>> to zones on same subnet? Also I saw that this functionality was >>> backported to Solaris 10 zoneadm patch, but it mentiones TX zones. >>> Does this only apply to TX or regular zones as well? >>> >>> >>> >> ___ >> zones-discuss mailing list >> zones-discuss@opensolaris.org >> > > ___ > zones-discuss mailing list > zones-discuss@opensolaris.org > ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Shared-ip zones with defrouter
Max, The default route option is not specific to TX zones. However, it is intended for environments where your zones aren't sharing the same physical interfaces. This feature sets the default route for an interface so I don't think it will provide the functionality you are looking for. --Glenn Max Levine wrote: > Hi, > > We have a need to define a separate defaultroute for some of the > shared-ip zones in our environment. All of the zones are on the same > subnet, but only some need to have a different default route. I was > reading psarc/2008/057 but I am confused if the functionality applies > to zones on same subnet? Also I saw that this functionality was > backported to Solaris 10 zoneadm patch, but it mentiones TX zones. > Does this only apply to TX or regular zones as well? > > ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zones/SNAP design
Jerry,
For Trusted Extensions in OpenSolaris, we plan to use a new "labeled"
brand for zones which will be derived from the new ipkg brand. So your
proposal also affects "labeled" branded zones. I would like to explore
the plan to delegate these datasets to the zone. Since the zone's root
dataset must be mounted in the global zone before the zone can be
booted, this is distinct from the normal dataset delegation, in which
the mount is done from within the zone. For TX there are some issues
with ensuring that these datasets are properly protected and labeled.
There may also be issues with encryption keys.
For TX we would like a way to associate a label with a dataset even if
it isn't mounted. Today we derive the label from the ZFS mount attribute
which corresponds to the zonepath defined in zonecfg. Given a zone name,
we can find the label in /etc/security/tsol/tnzonecfg. However, with
multiple datasets being delegated to zones, and the use of the legacy
mount setting, the link between the dataset and it's label becomes a bit
weaker. For greater assurance, I would like to store the label as a
dataset property, but this implies it must not be delegated to the zone
since labels are only managed from the global zone.
I'm not clear about the security policy of properties, such as
org.opensolaris.libbe:parentbe. Is the ability to modify these
properties granted when the dataset is delegated? Can there by
properties that don't get delegated?
There is tangential issue with respect to NFS sharing of directories
within delegated zone datasets. Currently there is a TX extension to
zoneadmd which allows per-zone shares to be interpreted when zones are
booted or halted. Since this code must execute in the global zone, the
dataset must be previously mounted in the global zone. Delegated
datasets that aren't mounted from the global zone can't be shared today.
This issue isn't completely relevant to your proposal, but I wanted to
mention it for clarity.
--Glenn
Jerry Jelinek wrote:
> Apologies for any duplicates you might receive. This
> was sent to caiman-discuss, but for those who don't follow
> that list, I wanted to send this out here.
>
> Thanks,
> Jerry
>
>
>
> Zones/SNAP Design
> 8/25/2008
>
> I. Overview
>
> This specification describes how ZFS datasets will be used with zones for
> supporting software management operations with ipkg branded zones on
> OpenSolaris. Software management includes tasks such as a SNAP upgrade or
> installing/removing pkgs.
>
> Issues are summarized in Part III.
>
> One goal is that sw management behavior within the zone should be as similar
> as possible to the behavior in the global zone. That is, when the zone admin
> does sw management, the tools running within the zone should be able to take a
> snapshot of the zone root, clone it, and the zone admin should be able to
> roll-back if the sw installation was problematic. This implies that the zone
> root itself must be a delegated dataset. Up to now, zones does not support
> this, so we must extend zones to provide this capability.
>
> (Note that these software management features within a zone are not a
> requirement for the 2008.11 release, however, this proposal lays the
> groundwork to enable that capability moving forward.)
>
> There are some issues with delegating the zone root dataset to the zone. The
> way zones work, it is fundamental that the zone root be mounted in the global
> zone so that the system can set up the chrooted environment when the zone
> boots or when a process enters the zone. However, the ZFS mountpoint property
> cannot be interpreted from the global zone when a dataset is delegated,
> since this could lead to security problems.
>
> (Note that the zone root is {zonepath}/root as seen in the global zone}
>
> To address this, the zones code must be enhanced to explicitly manage the zone
> root mounts. This naturally falls out of the basic design described here.
>
> There were two alternative proposal considered; a two-level zone layout and a
> single-level zone layout. After much discussion, the single-level approach
> was chosen. The two-level approach is not described further here.
>
> II. Description
>
> To support the management of boot environments (BEs) for zones within both the
> global zone context as well as the non-global zone context, a nested,
> two-level, BE dataset naming scheme is used so that there is a top-level
> global zone BE namespace, as well as a zone-level BE namespace for the zone's
> own use. Properties on the zone's datasets are used to manage which dataset
> is active and which datasets are associated with a specific global zone BE.
>
> There are two properties on a zone's datasets that are used to manage the
> datasets; "org.opensolaris.libbe:parentbe" and "org.opensolaris.libbe:active".
>
> The "org.opensolaris.libbe:parentbe" property is set to the UUID of the global
> zone BE that is active when the non-global zone BE is creat
Re: [zones-discuss] Default Routes for Zones
Your proposed suggestion made sense to me, but it was deferred while we worked on exclusive IP stacks for zones, and other enhancements. However, it seems that this problem still requires a solution, so I've submitted the following project proposal to PSARC: 2008/057 Default Route For Zones http://www.opensolaris.org/jive/thread.jspa?threadID=50456&tstart=0 Hopefully this will be putback to Nevada soon, and backported to Solaris 10. --Glenn This message posted from opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Performance observations when hundreds of zones are made "ready"
When deploying zones in Trusted Extensions some customers want to boot many zones (hundreds) into the ready state. Since each zone has a unique label and zfs dataset their filesystems be used by label-aware services in the global zone such as NFS and sendmail, even when no processes (except zsched) are running. When a user requests an operation that requires starting processes in one of these ready zones, it is booted into the running state. I have been doing some analysis of performance bottlenecks when large numbers of zones are installed on a system. I can quickly clone hundreds of zones in a few minutes. Since all these zones share their network interfaces (and IP addresses) with the global zone, the only difference between the various zone config files is the root path. However, there is considerable overhead in the zones SMF service when booting the system even though they are all set to autoboot=false. I'm running under Parallels on a MacBook Pro. The zones service goes into maintenance because it takes too more than a minute to determine that it has nothing to do. I took a look at the service method, /lib/svc/method/svc-zones. In Solaris 10 the zones are booted using ctrun, but that it not done in Nevada. It seems to me that the ctrun command isn't really needed. The more interesting issue is that the zones are booted in background (with an &), instead of sequentially. I made a copy of this script and changed it so that it would boot zones into the ready state, and would run the zoneadm commands sequentially, instead of in background. I found that I go much better system performance, and was able to make 500 zones ready in about 25 minutes. When I ran the zoneadm commands in background, however, it never finished. The system just got bogged down in devfsadm which accumulated 500 threads. I ran this on both Solaris 10 and Nevada, and got different results, but the general story was the same. In Nevada, the HAL daeom, hald, was kept very busy because it wakes up on system event every time an entry is added to the global zone mnttab. Sinc e all the zone mnttab entries also show up in the global zones, it was continuously re-reading mnttab. When I ran the 500 instances of zoneadm sequentially, I only saw 8 threads for devfsadm instead of 500, and the system remained usable (for example the pointer tracked smoothly) while all the zones were made ready. Another issue that affects performance is that every zone is verified against every other zone for conflicts such as root paths every time they are started. I would like to see something like a timestamp on the the /etc/zones/index file that indicates that nothing has changed since the last time all the zones were installed and verified. I tested this by bypassing some of these checks in my own copy of devfsadm and zoneadm. It seemed to help by about 10% once the number of installed zones exceeded 300. This message posted from opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] dbus in local zones
Jordan Brown (Sun) wrote: > Glenn Faden wrote: >> I thought I answered that. The dbus-daemon is using a UNIX domain >> rendezvous file in /tmp in the global zone. The non-global zones have >> their own instances of /tmp, so the rendezvous file does not exist in >> their namespace. Even if it did, there would be other problems >> because the devices that get reported to HAL by the dbus-daemon don't >> exist in the non-global zones. HAL isn't zone-aware. > > I understood that. What I didn't understand was why there wasn't a > completely separate instance of the dbus-daemon running in each zone, > with its own rendezvous file for communicating with clients in that > zone. Why would you expect there to be cross-zone communication here? Some kind of zone-awareness needs to be integrated into HAL and/or dbus to deliver notification events (like hot plugging) to appropriate consumers. I don't have a proposal at this point. --Glenn ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] dbus in local zones
I thought I answered that. The dbus-daemon is using a UNIX domain rendezvous file in /tmp in the global zone. The non-global zones have their own instances of /tmp, so the rendezvous file does not exist in their namespace. Even if it did, there would be other problems because the devices that get reported to HAL by the dbus-daemon don't exist in the non-global zones. HAL isn't zone-aware. --Glenn Jordan Brown (Sun) wrote: >>> dbus-daemon cannot be run in non-global zones >>> > > Sure sounds like the question is "why not?". > > ___ > zones-discuss mailing list > zones-discuss@opensolaris.org > ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] dbus in local zones
D-Bus is an IPC daemon for GNOME, which is somewhat like Tooltalk in CDE. There is a good summary of D-Bus on Wikipedia: http://en.wikipedia.org/wiki/D-Bus D-Bus relies on UNIX domain sockets for communication with clients. UNIX domain sockets are not supported between zones. Generally D-Bus failures aren't fatal; apparently SciTE is an exception. Getting D-Bus to work across zones is a effort that is being investigated by the Trusted Extensions project. We currently use device allocation instead of D-Bus to access hot-pluggable devices in non-global zones. But using D-Bus would provide more compatibility with standard GNOME. --Glenn Bernd Schemmer wrote: > Hi > > I succesfully compiled the editor SciTE for Solaris and it works without > problems in the Global Zone. > > But in a non-global zone it does not fully work: > > I can start the editor with a file and edit that file but trying to > open a file from within the editor crashes the editor: > > [Sun Jan 13 21:36:05 [EMAIL PROTECTED] /var/develop/scite/scite/gtk] > # ../bin/SciTE > process 25006: D-Bus library appears to be incorrectly set up; failed to > read machine uuid: Failed to open "/var/lib/dbus/machine-id": No such > file or directory > See the manual page for dbus-uuidgen to correct this issue. > D-Bus not built with -rdynamic so unable to print a backtrace > Abort (core dumped) > > [Sun Jan 13 21:37:13 [EMAIL PROTECTED] /var/develop/scite/scite/gtk] > # ls /var/lib/dbus/machine-id > /var/lib/dbus/machine-id: No such file or directory > > When I look at the dbus service in the zone I see that it is disabled > > [Sun Jan 13 21:37:35 [EMAIL PROTECTED] /var/develop/scite/scite/gtk] > # svcs -a | grep dbus > disabled 18:38:52 svc:/system/dbus:default > > and according to the log file of the service it cannot be run in a > non-global zone: > > dbus-daemon cannot be run in non-global zones > > Because I don't know exactly for what the dbus daemon is used I would > like to know, if I can work around this error from Solaris (e.g. by > creating the missing file manually) or do I have to check the > application to not use the dbus at all? > > (My test environment is Solaris snv_78 for SPARC) > > regards > > Bernd > > > ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Problem with roles opening Console
Can you clarify whether you are seeing this problem with TJDS and/or TCDE? Also, please move this discussion to security-discuss. That is where Trusted Extensions discussions should take place. --Glenn Danny Hayes wrote: > We are running Solaris 10 U4 w/ Trusted Extensions on x86. When we open a > console/terminal as the primaryadmin role in a labeled-zone the > console/terminal window appears in the user’s workspace instead of the roles > workspace as you would expect. When opening a console/terminal at > unclassified “/dev/console: invalid argument attempt to make tty the console > failed” appears in /export/home/primaryadmin/.dt/errolog in the unclassified > zone. When we open a console/terminal as the primaryadmin role in the global > zone the console/terminal appears in the roles workspace as you would expect. > Even though the console/terminal opened in the correct workspace we received > “/dev/console: Permission Denied –C console access denied” in > /export/home/primaryadmin/.dt/errolog in the global zone. Our primaryadmin > role is configured as instructed in the Trusted Extensions Installation and > Configuration guide with Primary Administrator granted rights. This behavior > is consistent for all roles listed in the Trusted Extensions Installation and > Configuration guide. Is this a known issue or am I missing something? > > > This message posted from opensolaris.org > ___ > zones-discuss mailing list > zones-discuss@opensolaris.org > ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] NFS: Cannot share a zfs dataset added to a labeled zone
I took another look at this configuration, and have yet another suggestion. Instead of specifying the zfs dataset using zonecfg's datatset keyword, where it is mounted by the zone, you can just specify that it should be mounted by zoneadm, instead. I previously suggested doing this: zonecfg:zone-name> add dataset zonecfg:zone-name:dataset> set name=zone/data zonecfg:zone-name:dataset> end But that delays the dataset from being mounted until after the dfstab file is interpreted. To get it mounted earlier (by zoneadm) you should do this instead: zfs set mountpoint=legacy zone/data zfs set zoned=off zone/data zonecfg:zone-name> add fs zonecfg:zone-name:fs> set dir=/data zonecfg:zone-name:fs> set special=zone/data zonecfg:zone-name:fs> set type=zfs zonecfg:zone-name:fs> end This causes the dataset to be mounted in the zone (at /data) before the dfstab file gets interpreted. The /zone/zone-name/etc/dfs/dfstab file should use the pathname (/data), too. share -F nfs /data There are subtle differences between the two approaches. Giving the dataset to the zone allows the zone's administrator to remount it and set other properties. But mounting the dataset as a filesystem, the zone's administrator no longer has that control. --Glenn This message posted from opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [security-discuss] NFS: Cannot share a zfs dataset added to a labeled zone
There are some interesting ordering issues with respect to the steps required for this configuration: 1. The dataset's mount point must be within the zone's root path for it to be mounted read-write within that zone (you can't use lofs). 2. The dataset should not be mounted (by the global zone) at the time the (restricted) zone is booted (or the zone boot fails). 3. The default mount point should be changed after the dataset is created before assigning the dataset to the zone. 4. The mount point can be changed from within that zone after it is mounted (but only to a pathname within the zone). 5. When you specify that the dataset belongs to the zone (via zonecfg) it is mounted by the zone when the SMF service filesystem/local runs. This happens after the "zoneadm boot" command completes. 6. The sharing of the mounted filesystem must be done from the global zone since labeled zones can't be NFS servers. When I looked at this more closely (after my second posting) I realized that it worked for me by accident (sorry). I did the share command by hand after I'd verified that the dataset was properly mounted in the restricted zone. But then I told you to edit the dfstab file without verifying that would work. As you have reported, that doesn't actually work. The problem is that the share command in the dfstab file is processed by the zoneadm command (while is running in the global zone) and normally occurs after all filesystems are mounted (or so I thought). However, in the case of zfs datasets, they actually get mounted later (by the zone itself, not by zoneadm), so you wind up sharing the mount point before it is actually mounted. That makes the mount point "busy", and causes the SMF service for mounting local filesystem to fail. The result is the zone is unusable. The obvious workaround is the remove the entry from dfstab, and do it later in the global zone. I don't have a very elegant solution for automating this. All I can think of is a script which does something like this: MP=your-global-zone-mount-path NOT_MOUNTED=1 while ($NOT_MOUNTED); do mount -p | grep $MP >/dev/null NOT_MOUNTED=$? sleep 1 done share $MP I haven't explored other solutions, but it may be possible to express interest in an SMF property to determine when the zone's local filesystem service has completed. It has been suggested that the share attribute could be specified via the zfs(1M) share option, but this won't work since it would be interpreted in the labeled zone instead of the global zone. Similarly the sharemgr doesn't seem to provide any special support for this case. Another source of confusion is the specification of the mount point. If you are setting it in the global zone, you need to prefix it with the zone's root path. But once the zone is running, it can be specified from within the zone. In that case, the zone's root path should not be specfied. Otherwise you get that string repeated, which is not what you want. I'm sorry this turned out to be a bit more complicated than I thought at first. But is can be made to work. --Glenn Danny Hayes wrote: > - I set the mount point as follows. > > zfs set mountpoint=/zone/restricted/root/data zone/data > > - I then added the dataset to the restricted zone using zonecfg. The full > path to the dataset is now /zone/restricted/root/zone/restricted/root/data. I > am not sure if that is what you intended, but it is a result of adding it as > a dataset to the zone after setting the mountpoint. > > - I updated the /zone/restricted/etc/dfs/dfstab with the following line. > > /usr/bin/share -F nfs -o rw /zone/restricted/root/zone/data > > - During reboot I receive the following error. > > cannot mount 'zone/data': mountpoint or dataset is busy > svc:/system/filesystem/local:default: WARNING: /usr/sbin/zfs mount -a failed: > exit status 1 > Oct 31 14:43:08 svc.startd[19960]: svc:/system/filesystem/local:default: > Method "/lib/svc/method/fs-local" failed with exit status 95. > Oct 31 14:43:08 svc.startd[19960]: system/filesystem/local:default failed > fatally: transitioned to maintenance (see 'svcs -xv' for details) > > - This is exactly the same problem that prompted the original message. > Service fail during boot which prevent opening a console. This only occurs > when you try to share the dataset. If you remove the line from > /zone/restricted/etc/dfs/dfstab and reboot the zone everything works fine. > Any ideas what I am doing wrong? > > > This message posted from opensolaris.org > ___ > security-discuss mailing list > [EMAIL PROTECTED] > ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] NFS: Cannot share a zfs dataset added to a labeled zone
I posted an earlier reply to zones-discuss, but I didn't copy all of the forums in the original posting. I'm doing so now. I am also correcting some errors in my earlier reply: Yes, it is possible to share a zfs dataset that has been added to a labeled zone. Set the mountpoint property of your dataset zone/data to be within the restricted zone's root. For example: # zfs set mountpoint=/zone/needtoknow/root/zone/data zone/data Then you should specify, using zonecfg, that the dataset is associated with the zone. zonecfg:zone-name> add dataset zonecfg:zone-name:dataset> set name=zone/data zonecfg:zone-name:dataset> end I previously stated that you didn't need to specify the dataset via zonecfg, if the zone is already running. However, in the general case, you should do so. If the dataset is mounted before the zone has been booted, zoneadm will fail to boot the zone because its file namespace it not empty. Then you should be able to share it via NFS, by editing the approriate dfstab file in the global zone. In this case, the dfstab file would be: /zone/restricted/etc/dfs/dfstab When the zone is booted, the dataset will be mounted automatically as a read-write mount point in the restricted zone with the correct label. A few subtle points: 1. Setting the zfs mountpoint property has the side-effect of settting its label if the mountpoint corresponds to a labeled zone. Only the global zone can do this. 2. The dataset will only be accessible while the restricted zone is ready or running. Note that it can be shared (via NFS) even when the zone is in the ready state. 3. Labeled zones which dominate the restricted zone (if any) can gain read-only access via NFS mounts (specifying an non-shared global zone IP address and the full pathname of the mounted dataset as viewed from the global zone. For example: /net/gz-name/zone/restricted/root/zone/data The second "zone" in the pathname is there because it was specified in the original posting, but you can rework the example without it. --Glenn This message posted from opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] NFS: Cannot share a zfs dataset added to a labeled zone
Please try the following: Set the mountpoint property of your dataset zone/data to be within the restricted zone's root. For example: # zfs set mountpoint=/zone/needtoknow/root/zone/data zone/data That will cause the dataset to appear automatically as a read-write mount point in the restricted zone with the correct label. You don't need to specify it via zonecfg. Then you should be able to share it via NFS. A few subtle points: 1. Setting the zfs mountpoint property has the side-effect of settting its label if the mountpoint is in a labeled zone. 2. The restricted zone's dataset must exist (but doesn't need to be running) before you can mount the new data set. 3. I think zfs mount code figures out dependencies automatically so if you reboot the restricted zone's dataset will be mounted before mounting the zone/data dataset. --Glenn Danny Hayes wrote: > Is it possible to share a zfs dataset that has been added to a labeled zone? > We are running Solaris 10 U4 w/ TX on x86. Currently, we have a zfs file > system named zone/restricted. We have a labeled zone named “restricted” > loaded to this zfs. The global path is /zone/restricted. We have another zfs > file system named zone/data that we want to add as a dataset to the > “restricted” zone. The original global path of this zfs file system is > /zone/data. The zone path for the zfs dataset after it has been added to the > “restricted” zone is /zone/restricted/root/zone/data. We would like to share > the data in the zone/data zfs with “restricted” labeled zones on other > systems in my network. We have successfully shared a directory created in the > “restricted” zone using /zone/restricted/etc/dfs/dfstab, but have been unable > to share the zfs dataset /zone/data. We chose to use a zfs dataset instead of > just creating a directory in the zone, because it is a large amount of data > with new versions released regularly. With each release the zfs can be > destroyed and restored from a snapshot containing the new data very quickly. > There is an error during boot up of the zone stating the dataset is busy and > cannot be mounted. This causes several services to fail and prevents opening > a terminal or console window. Is it possible to share a dataset that has been > added to a labeled zone? This is a major piece of our configuration and any > help with this issue would be greatly appreciated. I know this might sound > confusing, so I listed some paths and dfstab file below to help clarify. > Thanks > > [u]zpool[/u] > zone > > [u]zfs file systems[/u] > zone/restricted > zone/data > > [u]zone path after dataset added to zone[/u] > /zone/restricted/root/zone/data > > [u]contents of /zone/restricted/etc/dfs/dfstab[/u] > share -F nfs -o rw /zone/data > > > This message posted from opensolaris.org > ___ > zones-discuss mailing list > zones-discuss@opensolaris.org > ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Zones and 3D applications
It is not practical for each zone to have its own X server. The X server runs in the global zone, and can be accessed from non-global zones. You can also run Xnest in a non-global zone, but the actual keyboard/mouse/display are still under the control of the global zone. When Trusted Extensions is enabled, the global zone X server isolates the clients connected from different zones so that they cannot interfere or interact with each other. For example cut and paste between zones in not allowed by default. OpenGL and 3D operations will work if they don't require that the client has access to the hardware. Trusted Extensions also supports Sun Ray software with zones. All the X servers (per DTU) run in the global zone, but the window manager (CDE) or panel manager (JDS) has been extended to understand zones and associate workspaces with zones. --Glenn Amir Javanshir wrote: > Hi all, > > One of our partners who develops a PLM software (using OpenGL and 3D > accelerator cards), asked me a couple of tricky questions concerning > Solaris zones. > > First of all, we agree that Solaris zones (by extension the > containers) are really useful on the server side, for consolidation > means. However does it really make sense to use zones on a graphical > workstation ? What benefit would there be there ? (The only one I can > see is to have two different versions of a software on the same > workstation) > > Now the tricky questions: > > * In case of the sparse root zone many libraries are shared > between all the zones. What about the X11 libraries, colormap, > pixmap ans so on ? > * And in Whole Root Zones, do we get a different X server for > each zone ? > * Finally, lets say each zone has it's own X server, how can > dirrerent zones deal with the 3D graphic card on the workstation > (the XVR 2500 card for example) ? > > Putting it in other words, zones allow application to run in > protected environments, knowing nothing of other zones, each one > acting as if they are alones on the hardware. Can we guaranty > this behavior also for 3D graphical applications (two zones > running seamlessly different 3D applications, sharing the 3D card) > > Any help would be appreciated > Regards > > Amir > > > > ___ > zones-discuss mailing list > zones-discuss@opensolaris.org > ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [nfs-discuss] Re: [sysadmin-discuss] NFS server in zones
[EMAIL PROTECTED] wrote: I tend to agree, and the basic "server consolidation" target just makes sense. I want to pretend a zone is the box I used to have and not have to bump my nose on a funny behaviour or exceptions. However, there are some wrinkles: 2) Due to the above, it seems like the global zone admin should have a knob to turn to enable or disable the ability of a zone to share out files via NFS. Do people agree? For Trusted Extensions we generally don't want policy decsions, like what can be shared, to be made outside of the global zone. Therefore, a knob seems like a good idea. 3) I know we've talked about a zone not being able to share stuff outside of its namespace, but I wonder if we should further restrict this to sharing storage that's fully administered in the zone, e.g. you can't share a filesystem you got via lofs, but you can share from a /dev/dsk/cxtxdx or a zpool that had been fully delegated to you. Opinions? This seems like a good idea. Of course the zone's root directory is a special kind of lofs mount that is established during zone_create, so directories in that filesystem should be sharable. Even if the zone is created using zfs, the dataset's root is not in the zone. 4) A bug currently prevents a client instance and a server instance from being safe to use on the same box (apologies, can't quote the bugid from here). How likely, in your use case, is it that this will be a problem, i.e. will your boxes be in the position where a zone needs data shared from another zone as opposed to a separate server? This is a must fix. In TX we want to automount between labeled zones on the same machine. It seems to work with ZFS. Is the deadlock specific to UFS/NFS? --Glenn ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [nfs-discuss] Re: [sysadmin-discuss] NFS server in zones
Trusted Exensions already includes this functionality, although the implementation is not exactly what is being requested in this thread. In the case of Trusted Extensions, the global zone administrator determines which labeled zone directories may be exported via NFS. There is unique dfstab fiile for each labeled zone, but these files are not only visible and managed from the global zone. When a zone is booted (or made ready) its unique dfstab files is processed by the zoneadm daemon (in the global zone) and the appropriate directories are shared. When the zone is halted, the entries in the zone's dfstab are unshared. The MLS policy is automatically enforced in the kernel. Remote NFS clients must dominate the the zone's label to do read-only mounts of the labeled zone's exports. Label equality is required for remote read-write mounts. Although the implementation is probably adequate for current customers moving from Trusted Solaris 8, it has several limitations. For example, as Darren pointed out, secure NFS using Kerberos doesn't work well because we don't yet have a multilevel KDC. Another issue is that the labeled zone automounters can't use LOFS to mount directories exported from other zones running on the same host as themselves. Using NFS to mount a locally exported filesystem may cause a deadlock. There is a bug recorded about this for UFS, but I don't know if it has been seen with ZFS exports. If you have specific issues about Trusted Extensions, you should use the security-discuss forum instead of zone-discuss or nfs-discuss. --Glenn Josh Fisher wrote: Our company is a current consumer of Trusted Solaris 8 and we will be converting to Solaris 10 with TX. For the conversion to be final however we must wait for the Common Criteria EAL4+ CAPP, RBAC, and LSPP release of Solaris 10 with TX. We are currently using Solaris 10 Update 3 for testing. In Trusted Solaris 8 our data is seperated into clearances which range from unclass to Secret with compartments. Some of the classified data is shared out to other classified systems. In Solaris 10 with TX we will seperate our clearances with labeled zones. This is our reason nfs server functionality is needed in zones in Solaris 10 with TX. We will have classified data which only resides in a labeled zone which will need to be shared out to other systems with the same clearance. If any of this is confusing I will try to explain better if need be. Thanks. This message posted from opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] NFS exports from global zone holding local zone mount points open
This feature is not supported with standard Solaris. It is only supported in Trusted Extensions. There are at least two problems in standard Solaris. As you pointed out, the NFS sharing should not take place until the zone is booted, and it should be unshared when the zone is halted. TX does the share and unshare operations automatically at the right time (within zoneadmd). TX maintains separate dftstab files for each zone. Secondly, the pathname, e.g. /zones/myzone, is not searchable except by root.. So anything that was exported would not be available anyway. This is also fixed in TX by special casing the zonepath permissions for NFS. --Glenn Tillman, Gregory wrote: I understand that NFS-exports need to be done in the global zone, so I dutifully added: share -F nfs -o ro=stats.lmig.com /zones/myzone/root/logdir to /etc/dfs/dfstab of my global zone. But when the master system rebooted, the NFS export happened before the local zone could boot. So the zone could not mount this filesystem, because the mount point was busy, and the zone boot failed. The problem may also occur with a simple reboot of the local zone, I haven't tried that yet. This must be a common problem, so I wondered if there is a recommended solution. Thanks - greg ___ zones-discuss mailing list zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Re: How to start processes in non-global zone by a GZ process?
The only supported interface is the zlogin(1M) command. Take a look at the example, runwlabel, at the end of chapter 3 of the TX Developer's Guide: http://docs.sun.com/app/docs/doc/819-7312/6n992es14?a=view If you use the source browser, you can see that there is a private system call zone_enter(), but this is not currently a stable interface, and may change in the future. There is no external man page for zone_enter() but in the new world of OpenSolaris you can obviously find examples. It is currently used in a few places by the Trusted Extensions CDE and JDS desktops and in device allocation. For example, see: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/rmvolmgr/vold.c#473 If your intended use it related to labeled zones and Trusted Extensions, you should probably post follow up questions on the security community forum: http://www.opensolaris.org/jive/forum.jspa?forumID=37 This message posted from opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: RE: ?: named pipes between zones using shared filesystem
Steffen Weiberle wrote: Is it safe to generalize that non-LOFS file systems in Solaris 10 do not allow cross-zone interaction? procfs does not. namefs does not. tmpfs does not. sockfs does not. doors does not. What about all the others (I can't even name them all)? Doors can be used in Solaris for cross-zone communication if the rendezvous file is visible in each zone. TX has conditional code to disallow cross-zone doors unless one end is running in the global zone. TX has a pretty simple rule that no data can be written to by more than one zone because each zone has a unique sensitivity label. This applies to all file system mounts including NFS mounts. There is no equivalent rule for standard Solaris. So if you need to enforce mandatory data flow policies, you probably need TX. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: RE: ?: named pipes between zones using shared filesystem
Dan Price wrote: On Tue 12 Dec 2006 at 10:47AM, Glenn Faden wrote: Names pipes may be used between zones when Trusted Extensions is enabled. The policy for data flow between zones is generally more restrictive when TX is enabled, but in this case it is slightly more open. The specific policy difference is implemented in the function tsol_fifo_access(). Thanks Glenn. Is there any reason not to make this work for all zones, not just TX ones? In my opinion, this fix should apply to regular zones, not just TX. But I wasn't sure of the impact when I did this. Note that without this fix, even within a single zone, you can't create a named pipe between two processes if one is referencing the pathname through a lofs mount and the other is not. I don't see a security risk here, since explicit administrator intervention is needed fromt he global zone to set this up. I'm not sure I follow all the bit about lofs though-- what would be the set of steps needed to set this up from the global zone, if this actually worked? Somebody in the global zone (or zoneadmd) has to make the named pipe rendezvous appear in the other zone. So two zones can't do this on their own. That's the restriction that TX requires. OTOH, it all seems a bit hokey. Steffen, what problem are you trying to solve? Why not just use sockets? Some of our customers like the fact that the flow of information is unidirectional. You can't get that with sockets. --Glenn ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Re: RE: ?: named pipes between zones using shared filesystem
Names pipes may be used between zones when Trusted Extensions is enabled. The
policy for data flow between zones is generally more restrictive when TX is
enabled, but in this case it is slightly more open. The specific policy
difference is implemented in the function tsol_fifo_access().
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/fifofs/fifovnops.c#166
This policy is also depends a few other assumptions, such as that lofs mount
are established between zones when they are booted. One of the problems in the
standard implementation is that the fifofs logic doesn't follow lofs mounts to
find the real vnode. So the connection logic doesn't find a match since the
pathnames are in different file systems. The following code in fifovp() was
needed to record the proper vnode.
405 / * In Trusted Extensions cross-zone named pipes
406 * are supported subject to the MAC policy. Since
407 * cross-zone access is done using lofs mounts,
408 * it is necessary to use the real vnode so that
409 * matching ends of the fifo can find each other.
410 */
411 if (is_system_labeled()) {
412 vnode_t *rvp;
413
414 if (VOP_REALVP(vp, &rvp) == 0)
415 vp = rvp;
416 }
This message posted from opensolaris.org
___
zones-discuss mailing list
zones-discuss@opensolaris.org
[zones-discuss] Re: zone management and security
Michael Barto wrote: > This probably sacrilege, but some of these zone > security issues might > be better served with Secure Solaris, if the > security requirements are > this extreme (e.g . DOD). Adding complex security > always add complex > overhead. On the other hand locking out the global > zone to all purposes > and administrators except for managing zones (nothing > else) creates less > security overhead. Diving servers into manage sets > (this group, that > group, accounts payable, accounts receivable) instead > of sharing between > groups can also keep the security overhead low. > Everyone thinks they can > write programs to correct bad management instead of > trying to correct > bad management. I assume by *Secure Solaris* you are referring to Solaris Trusted Extensions (TX). As you point out the TX model for administration is completely different from standard Solaris. The global zone is only available to administrative roles. Normal users, non-global zones, and untrusted hosts cannot login to the global zone. Roles may be assumed via trusted desktop menus. RBAC roles are used for separation of duty, and zones are even more isolated from each other than in the standard Solaris configuration. No data flows between zones are permitted unless explicitly granted and managed by a global zone administrator. See: http://opensolaris.org/os/community/security/projects/tx/ This message posted from opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Question on user account config with zones
Jerry Jelinek wrote: I believe the problem is that the zone looks like a separate system so the automounter within the zone does not know to use lofs to mount the filesystem from the global zone; it uses nfs instead. Yes, but even if it knew it should use lofs, there is no way it can express this using current semantics. --Glenn ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Question on user account config with zones
[EMAIL PROTECTED] wrote: There is no way for the non-global zone automounter to convert these automounts from NFS to LOFS. Firstly, there is no API for the non-global zone to determine that the NFS server is, in fact, the global zone sharing the same kernel. It can easily tell this though. It's not obvious to me how the non-global zone can determine the hostname of its global zone unless the global zone puts that information somewhere (like in a new file). Secondly, even if it could make this determination, there is no way for the the NFS semantics to be turned into equivalent LOFS semantics because the exported pathname is outside of the non-global zone's root directory. That's just a small matter of programming :-) Seems like the kernel has to help out here. Since the non-global zone automounter is unaware and unable to do anything else, it will simply do an NFS mount. The problem is that CR 5065254 (NFS/UFS deadlock when system is both NFS server and client) is likely to cause a deadlock. "Might cause a deadlock". I don't think it's an unsurmountable problem but it needs a bit of smarts in automount and a bit of help from the global zone. I'd like to see this fixed, too.We have a workaround for Trusted Extensions, but it seems to be to hard for people to understand. --Glenn ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Question on user account config with zones
Paul Kraus wrote: On 7/31/06, Steffen Weiberle <[EMAIL PROTECTED]> wrote: > Home directories are more problematic; you will need to loopback mount > them into the local zones. Is the underlying problem being worked on, or is it worth an RFE to make this transparent (automount if remote, auto-lofs if local (not sure how to tell))? How are they more problematic ??? I must be missing something here ? If the home directories are auto-mounted, then work just like on a non-zoned system. NFS from remote servers is mounted via NFS, if the global zone is the home directory server, then the NFS mount is supposed to be converted into an LOFS mount (just as any auto-mount of a server by itself is). I haven't tried this yet, as none of our zoned systems are NFS server (yet), but home directory mounts from remote servers into non-global zones works just fine. There is no way for the non-global zone automounter to convert these automounts from NFS to LOFS. Firstly, there is no API for the non-global zone to determine that the NFS server is, in fact, the global zone sharing the same kernel. Secondly, even if it could make this determination, there is no way for the the NFS semantics to be turned into equivalent LOFS semantics because the exported pathname is outside of the non-global zone's root directory. Since the non-global zone automounter is unaware and unable to do anything else, it will simply do an NFS mount. The problem is that CR 5065254 (NFS/UFS deadlock when system is both NFS server and client) is likely to cause a deadlock. --Glenn ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] non-global zone on a workstation console
The scenario you are describing is exactly waht Solaris Trusted Extensions does. See: http://www.opensolaris.org/os/community/security/projects/tx/ --Glenn Rob Fisher wrote: I asked this question before, but I never got a satisfactory answer. Seems there are a lot more people around with a lot deeper knowledge of zones, so it might just be worth asking it again. Here's the scenario: I have a laptop. When it boots, it gives you the console login: prompt. (I don't use dtlogin.) When you log in, obviously, you log in to the global zone. When you run xinit, your X session runs in the global zone. What I want is to log in at the console, and be in a local zone. Then launch X, and have my session in a local zone. I don't want to pass through the global zone at all. That should be locked down tight and hidden away. Is this possible? Can the console login be attached to a zone? I don't want XDMCP, scripts, zlogin, or anything like that, just a clean way of booting up, sitting down, logging in, and not being in the global zone. I can think of hacks to achieve the same result, but I'm interested in this from a theory viewpoint too. Does anyone know if what I want to do is possible? thanks Rob This message posted from opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
