Bakul Shah wrote: > Some motivating examples may help. Perhaps you can show > 1. Initial state of the world (show with the help of a few ls) > 2. A sequence of commands to change it > 3. What the world looks like finally
I have actually documented these things in this manner in the ANTS paper that can be found at http://ants.9gridchan.org/doc/ants.ps and it also overlaps with the tutorial material presented at http//antfarm.9gridchan.org/tutorial and the related pages. Do you think it would be helpful or welcome to re-post some of this material here on 9fans? I have tried to document all of these things extensively as part of my work. > And a brief description why this would be desirable. And how > it compares with just using chroot. Most people here can > perhaps read rc code more readily than elaborate explanations! Part of the comparison is that "chroot" does not exist in Plan 9, so "rerootwin" is very similar to chroot in a conceptual sense. The desirability is simply that if you have multiple independent namespaces, you need a mechanism to move freely between them. The "rerootwin" script and namespace file is really very simple. After checking and preparing the namespace, rerootwin does: oldterm=oldterm.$pid oldwsys=oldwsys.$pid srvfs -p 0600 oldterm.$pid /mnt/term srvfs -p 0600 oldwsys.$pid /mnt/wsys And then does auth/newns into a custom parameterized namespace file which has binds like this: mount -c /srv/$oldterm $pivot/$oldterm mount -c /srv/$oldwsys $pivot/$oldwsys bind $pivot/$oldterm/dev/cons /dev/cons bind $pivot/$oldterm/dev/consctl /dev/consctl The reason you can't just use auth/newns and the standard namespace file is that if you do this when you are connected via cpu or drawterm, the standard namespace file will not re-bind the window system and so you won't be able to run gui programs in the new namespace. Rerootwin "passes the devices through" via srvfs so you can reroot to a new namespace but still start new GUI applications. > In *BSD a jail is more than chroot since it can also get access > to its own interfaces, networking stack, init process, devices > etc. And it can't look at the state of another jail or the > host. And another host on the net doesn't even know it is > talking to a jail. Yes I absolutely understand this and I have tried to be careful to emphasize that I am using "jails" as a way of understanding what I am talking about. What I am doing is not intended as full isolation, and is not intended for security - I actually write about this in the faq on the antfarm site. Talking about jails/vms is just the only way I know to express the idea of an independent group of processes which act to create a user-environment. In fact, the ANTS design is deliberately pursuing integration between these seperate namespaces rather than isolation. My goal is not to "isolate" each environment - it is to create environments which are independent, but share data freely and deliberately make use of resources from the other environments. So even though the core idea - "independent userspaces" - is similar, the implementation and purpose is very different. I am trying to make the independent namespaces so that each namespace can serve a different function or role within the network - not impose security and isolation on users. The most important separate namespace is the kernel-device only namespace, which acts as an admin/launching layer for the other user namespaces. > To do something similar you will have to constrain each jail > to see a subset of processes, give it its own /dev, /env etc. > Not sure how you do this. As explained above (just to be clear) I am deliberately not doing this, because it is not the intended purpose. It would be possible to adapt the ideas of ANTS into a more jail like framework by using a lot of RFNOMNT to isolate things and take other steps, but that isn't how I use these tools. I want independent namespaces so I can administer my fossil and my venti "from beneath" so that if the fossil or venti need to be stopped, I still have all my needed tools available. I want independent namespaces so I can have 9front and Bell labs at the same time and actually share namespace between the two as needed. In fact one of the major ideas in ANTS is using a 9p fs called "hubfs" to deliberately create persistent data connections between these independent namespaces. In the setup I use, each of my independent namespaces has access to persistent shells in every other namespace and every other machine - so the architecture is literally the exact opposite of "security and isolation" it is fluid data sharing between independent userspaces. I hope these answers have been relevant and that my tone is friendly and informative. :) Your questions are very appropriate and insightful, and I have made an attempt to extensively answer them in the documentation I have created. I have a full length paper, full standard Plan 9 manpages, additional textual documentation within the ants software folder, and five step-by-step tutorials done with pre-installed VMs which attempt to comprehensively explain how to use ANTS, how it is built, and what its purposes are. I really appreciate the interest! I hope I am responding and explaining in a clear way Ben Kidwell "mycroftiv"
