From: Jeff D. <jd...@ka...> - 2002-07-24 03:02:15
|
da...@da... said: > I've got UML running with only the 'linux' binary, a root image and a > tmpfs mounted tmp directory - I don't think there is anything else I > can remove from the chroot directory. I have a cunning plan to get UML running in a completely empty chroot. You definitely won't be able to remove anything else from that. The plan is to add a 'filemap=<filename>,<fd>' option to UML. You'd use it like 'filemap=root_fs,3 3<root_fs'. File opens within UML would go through a central interface that would check the list of files that are already assigned to descriptors. If the filename is there, it will just pass back the already-opened descriptor and not attempt to actually open the file. The linux binary itself would have to be present in the chroot, but it could be removed as soon as it is known to be running. The /tmp files pose something of a challenge since their names are randomly generated. We could possibly have filemap include some wildcarding to cover this case. > For network connectivity, I am currently creating 'dev/net/tun' within > my chroot, which is somewhat insecure - I'm assuming a DOS attack > could be started against the host by creating many tun/tap devices. This is a potential problem. I think I would like to have it closed somehow once it's been used to get a tap device. > What I am thinking of doing is creating a tap device, then connecting > 'uml_switch' to this tap device outside of the chroot, as the user > which will be executing the 'linux' binary within the jail, but point > uml_switch's control socket to a fifo within the chroot directory. Yeah, this sounds like a good plan. I've been using preconfigured tap devices in my jailing experiments. I need to start playing with the switch and see how that goes. Jeff |
From: Jeff D. <jd...@ka...> - 2002-07-25 02:59:54
|
da...@da... said: > How will that handle COW though? Is it as simple as feeding it two > file descriptors, Yup. > or will it need to be a little more complex, since > the COW file contains the path to the backing file, which we can't > verify from with the chroot. You have to know what the backing file is. The backing file verification is something I hadn't considered. I think fstat will do the trick, though. > I would think that 'linux' would have to clean up after itself, rather > than having an external process do it. Why? > I'd like to be able to delete the control file for uml_switch once > the UML is up, but I figure that if eth0 goes up and down, it's going > to need to access the socket and I'm not sure if it opens and closes > it when that happens. If it does, I think that's a bug. It shouldn't need to close and reopen the socket. Jeff |
From: David C. <da...@da...> - 2002-07-25 03:06:45
|
Jeff Dike wrote: >>I would think that 'linux' would have to clean up after itself, rather >> than having an external process do it. > > Why? Because I imagine it's somewhat difficult for another process to figure out when 'linux' has it's networking setup so we can unlink our uml_switch socket. Or maybe I'm confused. David -- David Coulson http://davidcoulson.net/ d...@vi... http://journal.davidcoulson.net/ |
From: Jeff D. <jd...@ka...> - 2002-07-25 03:46:21
|
da...@da... said: > Because I imagine it's somewhat difficult for another process to > figure out when 'linux' has it's networking setup so we can unlink > our uml_switch socket. True, however if the socket can be passed in as a file descriptor, that problem goes away. Unix sockets can also be in an abstract namespace rather than the filesystem, so you can pass in an abstract name and UML will be able to bind to it without it being accessible as a file. Jeff |
From: David C. <da...@da...> - 2002-07-25 13:06:58
|
Jeff Dike wrote: > Unix sockets can also be in an abstract namespace rather than the filesystem, > so you can pass in an abstract name and UML will be able to bind to it > without it being accessible as a file. How do I do that? David -- David Coulson http://davidcoulson.net/ d...@vi... http://journal.davidcoulson.net/ |
From: Jeff D. <jd...@ka...> - 2002-07-25 13:27:27
|
da...@da... said: > How do I do that? Abstract names start with '\0'. So, just construct a name with a zero first character and bind to it. Jeff |
From: David C. <da...@da...> - 2002-07-25 13:33:29
|
Jeff Dike wrote: > Abstract names start with '\0'. So, just construct a name with a zero first > character and bind to it. So I can just do; mkfifo \0socket Then point the UML to '\0socket' without supplying a path? David -- David Coulson http://davidcoulson.net/ d...@vi... http://journal.davidcoulson.net/ |
From: Jeff D. <jd...@ka...> - 2002-07-25 15:24:16
|
da...@da... said: > mkfifo \0socket No, you don't do anything in the filesystem. Just have one process bind to the \0name and have another connect to it. Jeff |
From: John H. <joh...@ce...> - 2002-07-25 15:53:46
|
On Thu, 2002-07-25 at 18:27, Jeff Dike wrote: > da...@da... said: > > mkfifo \0socket > > No, you don't do anything in the filesystem. Just have one process bind > to the \0name and have another connect to it. > One Process to rule them all, One Process to find them, One Process to connect them all and in the darkness bind them.... Say, where have I heard this before? |
From: David C. <da...@da...> - 2002-07-25 17:58:02
|
Jeff Dike wrote: > No, you don't do anything in the filesystem. Just have one process bind > to the \0name and have another connect to it. Ah, so I do; uml_switch -unix \0whatever then; linux eth0=daemon,unix,,\0whatever David -- David Coulson http://davidcoulson.net/ d...@vi... http://journal.davidcoulson.net/ |
From: David C. <da...@da...> - 2002-07-25 00:54:43
|
Jeff Dike wrote: > The plan is to add a 'filemap=<filename>,<fd>' option to UML. You'd use it > like 'filemap=root_fs,3 3<root_fs'. File opens within UML would go through > a central interface that would check the list of files that are already > assigned to descriptors. If the filename is there, it will just pass back > the already-opened descriptor and not attempt to actually open the file. How will that handle COW though? Is it as simple as feeding it two file descriptors, or will it need to be a little more complex, since the COW file contains the path to the backing file, which we can't verify from with the chroot. > The linux binary itself would have to be present in the chroot, but it > could be removed as soon as it is known to be running. I would think that 'linux' would have to clean up after itself, rather than having an external process do it. Any chance of a 'cleanup' or 'chroot' switch, so after opening specific files on the host, UML unlinks them? > The /tmp files pose something of a challenge since their names are randomly > generated. We could possibly have filemap include some wildcarding to cover > this case. Indeed - /tmp is a bit of a pain. I'll let you deal with that one. > Yeah, this sounds like a good plan. I've been using preconfigured tap > devices in my jailing experiments. I need to start playing with the > switch and see how that goes. I currently have my switch creating it's fifo in a directory, then hard linking that file into each of the chroot directories for the UMLs - I'd like to be able to delete the control file for uml_switch once the UML is up, but I figure that if eth0 goes up and down, it's going to need to access the socket and I'm not sure if it opens and closes it when that happens. I guess this could be another filemap thing. David -- David Coulson http://davidcoulson.net/ d...@vi... http://journal.davidcoulson.net/ |