Hello, I''m courious about how to implement access control lists for our Dom0. I read some articles about sHype/ACM and Xen. But haven''t found any practical documentation on how to really implement this. I''d need some basic features like allowing a certain user group to start/stop/pause/unpause a domain (without giving them root access to the dom0). Maybe also permissions to create new domains (within limits or based on templates)... I found the enomalism project, which looks really promising (http://www.enomalism.com/) but if such things work with a nice web-gui how could it be done with plain Xen? Thanks, Reinhard -- Dipl.-Ing. Reinhard Brandstaedter ZID - Zentraler Informatik Dienst Johannes-Kepler-Universitaet Linz Altenbergerstrasse 69 A-4040 linz phone: +43 732 2468 1368 email: reinhard.brandstaedter@jku.at _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Mon, Apr 30, 2007 at 10:02:15AM +0200, Reinhard Brandst?dter wrote:> I''d need some basic features like allowing a certain user group to > start/stop/pause/unpause a domain (without giving them root access to the > dom0). Maybe also permissions to create new domains (within limits or based > on templates)...I wrote a simple console-based shell to allow users to do that, and also gain access to the serial console: http://xen-tools.org/software/xen-shell> but if such things work with a nice web-gui how > could it be done with plain Xen?It is tricky because to use the "xm" command you need root, and you can''t just allow "sudo xm ..." unless you trust your users with a) remote access, and b) to stay with their own instance. Hence my shell! You could write a script: /usr/local/bin/vm-reboot-skx /usr/local/bin/vm-shutdown-skx etc. Where "skx" is the name of the instance and then give the local user skx sudo access to only their own scripts. If you have one or two users that is manageable, but it isn''t pleasant.. Steve -- Debian GNU/Linux System Administration http://www.debian-administration.org/ _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Monday 30 April 2007 12:39:31 Steve Kemp wrote:> On Mon, Apr 30, 2007 at 10:02:15AM +0200, Reinhard Brandst?dter wrote: > > I''d need some basic features like allowing a certain user group to > > start/stop/pause/unpause a domain (without giving them root access to the > > dom0). Maybe also permissions to create new domains (within limits or > > based on templates)... > > I wrote a simple console-based shell to allow users to do that, and > also gain access to the serial console: > > http://xen-tools.org/software/xen-shellThis looks pretty promising and of course I had to try it immediately. If I understand the documentation right you have to add an xen_shell="username" to the domU configuration to allow a user to control this domU. I did so and then launched xen-shell (or xen-login-shell) however the shell gives me some errors (doesn''t understand most of the commands): xen-shell v1.1.80 - type ''help'' for help. xen-shell> help xen-shell v1.1.80 The following commands are available within this shell: boot - Boot the Xen guest. console - Gain access to a Xen guest via the serial console. exit - Exit the shell. help - Show general, or command-specific, help information. passwd - Change the password used to access this host. quit - Exit this shell. reboot - Reboot the Xen guest. serial - Gain access to the Xen guest via the serial console. shutdown - Shutdown the Xen guest. status - Show the status of the Xen guest. top - Show system resource usage. uptime - Show the uptime information of your guest system and this host. version - Show the version of this shell, and of Xen. For command-specific help run "help command". xen-shell> list Unknown command: ''list'' - type ''help'' for help. xen-shell> boot You have no selected a Xen instance to control, and this command applies to only one instance rather than all of them. You may use the following two commands: list -> Show which Xen instances you may control. control -> Take control of the specified Xen instance. If i use the ''top'' command I get a list of all running domUs (when running the shell as root). Reinhard _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Wednesday 02 May 2007 08:56:11 Reinhard Brandstädter wrote:> On Monday 30 April 2007 12:39:31 Steve Kemp wrote: > > On Mon, Apr 30, 2007 at 10:02:15AM +0200, Reinhard Brandst?dter wrote: > > > I''d need some basic features like allowing a certain user group to > > > start/stop/pause/unpause a domain (without giving them root access to > > > the dom0). Maybe also permissions to create new domains (within limits > > > or based on templates)... > > > > I wrote a simple console-based shell to allow users to do that, and > > also gain access to the serial console: > > > > http://xen-tools.org/software/xen-shell > > This looks pretty promising and of course I had to try it immediately. > If I understand the documentation right you have to add an > xen_shell="username" to the domU configuration to allow a user to control > this domU. > > I did so and then launched xen-shell (or xen-login-shell) however the shell > gives me some errors (doesn''t understand most of the commands): > > xen-shell v1.1.80 - type ''help'' for help. > xen-shell> help > xen-shell v1.1.80 > > The following commands are available within this shell: > > boot - Boot the Xen guest. > console - Gain access to a Xen guest via the serial console. > exit - Exit the shell. > help - Show general, or command-specific, help information. > passwd - Change the password used to access this host. > quit - Exit this shell. > reboot - Reboot the Xen guest. > serial - Gain access to the Xen guest via the serial console. > shutdown - Shutdown the Xen guest. > status - Show the status of the Xen guest. > top - Show system resource usage. > uptime - Show the uptime information of your guest system and this > host. version - Show the version of this shell, and of Xen. > > For command-specific help run "help command". > > xen-shell> list > Unknown command: ''list'' - type ''help'' for help.The reason for this behavior was that the user using the xen-shell didn''t have rights to read the /etc/xen directory. with the right permissions xen-shell shows the available machines. However there is a problem with machines which names are created dynamically with parameters. e.g. I''m using a DomU config script that contains: /etc/xen/apache name = "apache-%d" %vmid and can be used to create multiple DomUs with a commandline parameter to xm: ''xm create apache vmid=1'' the resulting VMs is named ''apache-1''. So xen-shell won''t find that a user has access to those machines. I see two ways to solve this problem: 1.) either make xen-shell aware of wildcards. If a domU ''name='' contains any %d in the xen config, all VMs that match are added to the user''s access list. 2.) everytime a domain is created and its name is based on a wildcard create a ''dummy'' xen config file that only contains the resulting domain name and the xen_shell attribute. e.g. for me that would be: /etc/xen/apache-1 name = "apache-1" xen_shell = ''apacheadm'' Any other ideas? Reinhard _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Wed, May 02, 2007 at 10:46:37AM +0200, Reinhard Brandst?dter wrote:> > This looks pretty promising and of course I had to try it immediately.:)> The reason for this behavior was that the user using the xen-shell didn''t have > rights to read the /etc/xen directory. with the right permissions xen-shell > shows the available machines.I''ll add a check to make sure that is reported accurately at startup.> 1.) either make xen-shell aware of wildcards. If a domU ''name='' contains > any %d in the xen config, all VMs that match are added to the user''s access > list.That seems like it would be less general than I''d like.> 2.) everytime a domain is created and its name is based on a wildcard create > a ''dummy'' xen config file that only contains the resulting domain name and > the xen_shell attribute. e.g. for me that would be: > > /etc/xen/apache-1 > name = "apache-1" > xen_shell = ''apacheadm''That is the solution I''d propose since it fits your usage, and requires no changes from me! Steve -- # Commercial Debian GNU/Linux Support http://www.linux-administration.org/ _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Wednesday 02 May 2007 11:10:21 Steve Kemp wrote:> > 2.) everytime a domain is created and its name is based on a wildcard > > create a ''dummy'' xen config file that only contains the resulting domain > > name and the xen_shell attribute. e.g. for me that would be: > > > > /etc/xen/apache-1 > > name = "apache-1" > > xen_shell = ''apacheadm'' > > That is the solution I''d propose since it fits your usage, and > requires no changes from me!However this would mean that the user would not be able to start this machine, as it''s config file is incomplete (only contains name and xen_shell). Only the superuser could start/create the machine using the ''real'' config file ''apache''. What would help here was an ''include'' statement for the xen domain config: ''/etc/xen/apache'' contains all the general setting needed for a domU instance and ''apache-1'' contains the name and the user permission list for xen_shell. e.g. in ''apache'' you add include = ''apache-%d'' %vmid so you could still create VMs with ''xm create apache vmid=1'', keep all the general things in ''apache'' config file and the user/xen_shell specific in the ''apache-1'' ''apache-2'' files. Two other things related to this: why is there no command for pause/unpause a domain? Is it possible to pass parameters to the boot command? Reinhard _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Wed, May 02, 2007 at 12:53:54PM +0200, Reinhard Brandst?dter wrote:> However this would mean that the user would not be able to start this machine, > as it''s config file is incomplete (only contains name and xen_shell). Only > the superuser could start/create the machine using the ''real'' config > file ''apache''.I guess that is true. I''ll have to think about this some more.> What would help here was an ''include'' statement for the xen domain config:Agreed.> Two other things related to this: why is there no command for pause/unpause a > domain? Is it possible to pass parameters to the boot command?Pause and unpause were missing because they didn''t seem required for my hosting setup! I''ll add them to CVS this afternoon and have a new release out by the end of the week. There are no options passed to the boot command at all right now, if you could give me an example of the kind of use that you''d like I can see about adding it. (Though I guess you''re talking about ids again, right?) Adding support for "boot foo=bar extra1" would be mostly trivial. The only thing to watch out for shell escapes. Steve -- _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Wednesday 02 May 2007 13:55:41 Steve Kemp wrote:> > What would help here was an ''include'' statement for the xen domain > > config: > > Agreed.Maybe some of the xen developers reads this and thinks it''s a good idea too :-)> > Two other things related to this: why is there no command for > > pause/unpause a domain? Is it possible to pass parameters to the boot > > command? > > Pause and unpause were missing because they didn''t seem required for > my hosting setup! I''ll add them to CVS this afternoon and have a new > release out by the end of the week.Thanks, great!> There are no options passed to the boot command at all right now, > if you could give me an example of the kind of use that you''d like I > can see about adding it. (Though I guess you''re talking about ids > again, right?) Adding support for "boot foo=bar extra1" would be > mostly trivial. The only thing to watch out for shell escapes.It is the ids I mentioned before, yes. When I pass it to xm create it is passed to the init process of the domU and is then used by other boot scripts (e.g. setting static IP adresses or mounting specific partitions). Reinhard _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users