Xen devel - Mar 2005 - [PATCH] xen-2.0: privileged port connections

Hi,

as discussed previously, I went ahead and introduced a setting that
allows you to restrict the stuff you can when controlling xen by
connecting to the port 8000 unless you connect from a privileged
port.

I did not yet bother to look at the event port nor did I try to address
the consoles. The consoles will be done in a second patch if this 
approach is deemed appropriate. 

Note that I also do still allow unprivileged connections still to gather
most of the information. This can be debated, but I''m not such a big
fan
of security by obscurity.

I hope I did not miss anything important for the control stuff.

The patch also fixes one typo (missing ") in SrvNode.py.

Regards,
-- 
Kurt Garloff                   <kurt@garloff.de>             [Koeln, DE]
Physics:Plasma modeling <garloff@plasimo.phys.tue.nl> [TU Eindhoven, NL]
Linux: SUSE Labs (Director)    <garloff@suse.de>            [Novell Inc]

So, here''s my concerns:

1) ports < 1024 are reserved although 732 is currently unassigned
2) unix domain sockets would solve the same problem
3) this approach is not flexible for finer grain control
4) you still have to find a way to deal with the consoles
5) you still have to deal with xfrd

With all that said, I''d like to see this applied as it''s
better than
leaving everything out in the open.

Regards,
Anthony Liguori

Kurt Garloff wrote:
>Hi,
>
>as discussed previously, I went ahead and introduced a setting that
>allows you to restrict the stuff you can when controlling xen by
>connecting to the port 8000 unless you connect from a privileged
>port.
>
>I did not yet bother to look at the event port nor did I try to address
>the consoles. The consoles will be done in a second patch if this 
>approach is deemed appropriate. 
>
>Note that I also do still allow unprivileged connections still to gather
>most of the information. This can be debated, but I''m not such a
big fan
>of security by obscurity.
>
>I hope I did not miss anything important for the control stuff.
>
>The patch also fixes one typo (missing ") in SrvNode.py.
>
>Regards,
>  
>


-------------------------------------------------------
This SF.net email is sponsored by: 2005 Windows Mobile Application Contest
Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones
for the chance to win $25,000 and application distribution. Enter today at
http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Hi Anthony,

On Wed, Mar 23, 2005 at 09:41:24AM -0600, Anthony Liguori
wrote:
> So, here''s my concerns:
> 
> 1) ports < 1024 are reserved although 732 is currently unassigned
Note that NFS uses such ports without asking prior permission.
I chose 732 because it''s unassigned indeed.
> 2) unix domain sockets would solve the same problem
Yes. There''s one but: 

With the patch you can currently configure xend from completely
open (xend-address '''' and xend-privileged-port 0)
to closed (xend-address ''localhost'' and xend-privileged-port
1)
except for root (and stuff I overlooked or did not do yet).

If you go for Unix Domain Sockets instead TCP, you lose the ability
of remote control. Unless you support both.

I did not investigate how difficult to do that would be.
If you have a patch, I''d volunteer to review :-)
> 3) this approach is not flexible for finer grain control
sudo, setuid, ... can provide that.
> 4) you still have to find a way to deal with the consoles
Before I start working on getting the consoles under control, I 
wanted to see whether this approach is acceptable at all.
> 5) you still have to deal with xfrd
It seems to listen on *:8002 ... 
Is there no authentication either? Sigh.

And we probably need to look into the event channel (8001) as well.
> With all that said, I''d like to see this applied as it''s
better than
> leaving everything out in the open.
For Xen-3.0, we may want to carefully chose what kind of backend (xend)
to frontend (xm) communication channels we want to allow and how
authentication and authorization is handled there.

But for Xen-2, let''s try to find a pragmatic way that enables desktop
users to install and test xen without raising too many security 
concerns.

Regards,
-- 
Kurt Garloff, Director SUSE Labs, Novell Inc.

Kurt Garloff wrote:
>Hi Anthony,
>
>On Wed, Mar 23, 2005 at 09:41:24AM -0600, Anthony Liguori wrote:
>  
>
>>So, here''s my concerns:
>>
>>1) ports < 1024 are reserved although 732 is currently unassigned
>>    
>>
>
>Note that NFS uses such ports without asking prior permission.
>I chose 732 because it''s unassigned indeed.
>
I know.  That''s one of the reasons using this port worries me.  There 
may be nfs related conflicts.
>>4) you still have to find a way to deal with the consoles
>>    
>>
>
>Before I start working on getting the consoles under control, I 
>wanted to see whether this approach is acceptable at all.
>  
>
How would you extend this to consoles?  Each console can''t have
it''s own
privileged port :-)
>>5) you still have to deal with xfrd
>>    
>>
>
>It seems to listen on *:8002 ... 
>Is there no authentication either? Sigh.
>  
>
Nope.  I think there are a few options.  We could use hosts.allow or 
something similiar, we could restrict it to subnets, or we could try and 
implement some sort of authentication mechanism.

Perhaps shutting it off by default and making it clear that it is 
insecure is enough.
>And we probably need to look into the event channel (8001) as well.
>  
>
Yeah.
>But for Xen-2, let''s try to find a pragmatic way that enables
desktop
>users to install and test xen without raising too many security 
>concerns.
>  
>
I full-heartedly agree.  I''ll gladly help out on this effort.

Regards,
Anthony Liguori
>Regards,
>  
>


-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content. 
Register
by 3/29 & save $300
http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Hi,

On Wed, Mar 23, 2005 at 11:03:39AM -0600, Anthony Liguori
wrote:
> >Note that NFS uses such ports without asking prior permission.
> >I chose 732 because it''s unassigned indeed.
> >
> I know.  That''s one of the reasons using this port worries me. 
There
> may be nfs related conflicts.
The NFS client just choses a free privileged source port as does xm.
Yes, the amount of NFS mounts is limited ...
And now xen competes with NFS, but neither should really tip over.
> >Before I start working on getting the consoles under control, I 
> >wanted to see whether this approach is acceptable at all.
> > 
> >
> How would you extend this to consoles?  Each console can''t have
it''s own
> privileged port :-)
Oh, that''s what I was planning to do. The privileged ports are less
scarce than the 4GB of memory that Xen-2 supports ...
We''ll hardly get running more than 64 virtual machines, I''d
guess.
> >>5) you still have to deal with xfrd
> >
> >It seems to listen on *:8002 ... 
> >Is there no authentication either? Sigh.
> >
> Nope.  I think there are a few options.  We could use hosts.allow or 
> something similiar, we could restrict it to subnets, or we could try and 
> implement some sort of authentication mechanism.
> 
> Perhaps shutting it off by default and making it clear that it is 
> insecure is enough.
We need to document it at least. Mazbe another setting in
xend-config.sxp ...
> >And we probably need to look into the event channel (8001) as well.
> >
> Yeah.
Any insight what we could do there?
> >But for Xen-2, let''s try to find a pragmatic way that enables
desktop
> >users to install and test xen without raising too many security 
> >concerns.
> >
> I full-heartedly agree.  I''ll gladly help out on this effort.
Thanks!

Regards,
-- 
Kurt Garloff, Director SUSE Labs, Novell Inc.

Kurt Garloff wrote:
>>1) ports < 1024 are reserved although 732 is currently unassigned
> 
> 
> Note that NFS uses such ports without asking prior permission.
> I chose 732 because it''s unassigned indeed.
With all due respect to the NFS folks, NFS is just not
a good example to follow in any aspect. Just picking an
unassigned port randomly won''t ensure a non-conflict.
>>2) unix domain sockets would solve the same problem
> 
> 
> Yes. There''s one but: 
> 
> With the patch you can currently configure xend from completely
> open (xend-address '''' and xend-privileged-port 0)
> to closed (xend-address ''localhost'' and
xend-privileged-port 1)
> except for root (and stuff I overlooked or did not do yet).
> 
> If you go for Unix Domain Sockets instead TCP, you lose the ability
> of remote control. Unless you support both.
> I did not investigate how difficult to do that would be.
> If you have a patch, I''d volunteer to review :-)
Yes, we can do this, allow users to select which protocol
they want. But picking one solution and resolving it''s
deficiencies in other ways would be simpler and cleaner
in the long run. Having the user make fewer infrastructure
decisions like this, the better. It also becomes an issue
when the distros need to ship with a fixed config.
>>3) this approach is not flexible for finer grain control
> 
> 
> sudo, setuid, ... can provide that.
The fewer such programs, the better for security, right?
>>4) you still have to find a way to deal with the consoles
> 
> 
> Before I start working on getting the consoles under control, I 
> wanted to see whether this approach is acceptable at all.
> 
> 
>>5) you still have to deal with xfrd
> 
> 
> It seems to listen on *:8002 ... 
> Is there no authentication either? Sigh.
> 
> And we probably need to look into the event channel (8001) as well.
Yep.
>>With all that said, I''d like to see this applied as
it''s better than
>>leaving everything out in the open.
Agreed.
> For Xen-3.0, we may want to carefully chose what kind of backend (xend)
> to frontend (xm) communication channels we want to allow and how
> authentication and authorization is handled there.
> 
> But for Xen-2, let''s try to find a pragmatic way that enables
desktop
> users to install and test xen without raising too many security 
> concerns.
Agreed.

thanks,
Nivedita




-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content. 
Register
by 3/29 & save $300
http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

> > 1) ports < 1024 are reserved although 732 is currently unassigned
> 
> Note that NFS uses such ports without asking prior permission.
> I chose 732 because it''s unassigned indeed.
Grabbing any port <1024 should do, there''s no need to just go for
732,
but have a series of ports that are tried. 
 
> > 2) unix domain sockets would solve the same problem
> 
> Yes. There''s one but: 
> 
> With the patch you can currently configure xend from completely
> open (xend-address '''' and xend-privileged-port 0)
> to closed (xend-address ''localhost'' and
xend-privileged-port 1)
> except for root (and stuff I overlooked or did not do yet).
> 
> If you go for Unix Domain Sockets instead TCP, you lose the ability
> of remote control. Unless you support both.
> 
> I did not investigate how difficult to do that would be.
> If you have a patch, I''d volunteer to review :-)
For Xen 2.x, unix domain sockets would be too much of a pain to
implement over Twisted. Kurt''s approach gets us closer toward
''secure by
default''.

Xen 3 will be very different.
> > 4) you still have to find a way to deal with the consoles
> 
> Before I start working on getting the consoles under control, I 
> wanted to see whether this approach is acceptable at all.
I think it''s a good band-aid.

Perhaps a better way to handle consoles would be to use
''screend'', and
then have incoming ssh connections dispatched to particular screen
sessions.
 
> > 5) you still have to deal with xfrd
> 
> It seems to listen on *:8002 ... 
> Is there no authentication either? Sigh.
> 
> And we probably need to look into the event channel (8001) as well.
Xfrd needs an option to listen only on localhost. (It''s still needed
for
save/restore even if you don''t use migrate).

The event channel only ever needs to be localhost (and could probably be
turned into a unix domain socket quite easily).


Ian


-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content. 
Register
by 3/29 & save $300
http://ads.osdn.com/?ad_idh83&alloc_id149&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Kurt Garloff wrote:
>Oh, that''s what I was planning to do. The privileged ports are less
>scarce than the 4GB of memory that Xen-2 supports ...
>We''ll hardly get running more than 64 virtual machines,
I''d guess.
>  
>
Maybe not the typical desktop user but that''s definitely not going to
be
the case for the enterprise user.  I do a lot of testing with small 
domUs and I routinely have 40+ domains running (16MB a piece) on my 1GB 
laptop.

On a 4GB system, with NFS in the picture, you could pretty easily 
exhaust the privileged ports with domains using between 32-64MB of 
memory (which is a pretty reasonable amount to allocate).  Throw in PAE 
support and you''ll run out quickly.

Would a patch to change Xend to use pty''s for consoles be accepted?  xm
console can be invoked via ssh to support remote consoles..
>Any insight what we could do there?
>  
>
I hate to beat a dead horse, but domain sockets seem like the obvious 
thing to do.  We don''t need different privilege levels there so that 
seems like the thing to do.

Regards,Anthony Liguori



-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content. 
Register
by 3/29 & save $300
http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

* Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> [2005-03-23
11:50]:
> > Before I start working on getting the consoles under control, I 
> > wanted to see whether this approach is acceptable at all.
> 
> I think it''s a good band-aid.
> 
> Perhaps a better way to handle consoles would be to use
''screend'', and
> then have incoming ssh connections dispatched to particular screen
> sessions.
Do you have a pointer to this ''screend''?  

Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253   T/L: 678-9253
ryanh@us.ibm.com


-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content. 
Register
by 3/29 & save $300
http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

On Wed, 23 Mar 2005, Kurt Garloff wrote:
> Oh, that''s what I was planning to do. The privileged ports are
less
> scarce than the 4GB of memory that Xen-2 supports ...
> We''ll hardly get running more than 64 virtual machines,
I''d guess.
I would expect ISPs to have more virtual machines than that,
for cheap "root on your own virtual machine" hosting accounts
with larger hardware.

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan


-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content. 
Register
by 3/29 & save $300
http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

> Would a patch to change Xend to use pty''s for consoles be 
> accepted?  xm 
> console can be invoked via ssh to support remote consoles..
I''m in favour of this in principle, but I think we need to think
through
precisely how the pty approach would work. 

There are a couple of other issues that we should consider at the same
time. I''ve heard a couple of users complain that they find our model of
exporting serial consoles confusing: when they quit a console session
and reconnect they find that they are still logged in. Worse, if they
were running vi when they quit the session they get very confused when
connecting back in. I guess if you''re not used to a serial console then
you would find the behaviour confusing. Should we be doing some more
complex terminal emulation?

Using something like ''screen'' in dom0 might help, so at least
upon
reconnecting the console window is ''refreshed'' to show its
previous
contents.

The other issue we need to consider is VM migration. Ideally, it should
be completely transparent to someone with a console connection open
(just like it is to someone with an ssh connection open). There are two
ways to do this, either have a console server machine for all the nodes
in a cluster, or hide the disconnect/reconnect in the client terminal
program. If we are using a ''standard'' program on the client
side (e.g.
ssh in an xterm), then the former is preferable. If for some reason we
choose to use a custom program (e.g. son-of-xencons) then we could
reasonably hide the relocation.

I''d like to see a decent discussion of how best to do consoles before
changing the status quo. 

Thanks,
Ian 


 


-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content. 
Register
by 3/29 & save $300
http://ads.osdn.com/?ad_idh83&alloc_id149&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Ian Pratt wrote:
>There are a couple of other issues that we should consider at the same
>time. I''ve heard a couple of users complain that they find our
model of
>exporting serial consoles confusing: when they quit a console session
>and reconnect they find that they are still logged in. Worse, if they
>were running vi when they quit the session they get very confused when
>connecting back in. I guess if you''re not used to a serial console
then
>you would find the behaviour confusing. Should we be doing some more
>complex terminal emulation?
>  
>
Perhaps we could export the console via a pty and then create a screen 
session by executing the equivalent of "screen vm-console domid".

Clients can then connect to it by executing screen -x (instead of 
connecting directly to the pty) and our client could translate C-] to 
C-a C-d to detach from the screen.  Any reconnects will perserve the 
screen of the previous session.

This way, we can still have minimalistic toolchains that provide serial 
style consoles.
>The other issue we need to consider is VM migration. Ideally, it should
>be completely transparent to someone with a console connection open
>(just like it is to someone with an ssh connection open). There are two
>ways to do this, either have a console server machine for all the nodes
>in a cluster, or hide the disconnect/reconnect in the client terminal
>program. If we are using a ''standard'' program on the
client side (e.g.
>ssh in an xterm), then the former is preferable. If for some reason we
>choose to use a custom program (e.g. son-of-xencons) then we could
>reasonably hide the relocation.
>  
>
One solution would be to do console-forwarding underneath the pty.

If you''re migrating from system A to system B and you are using ptys, 
your daemon that''s exposing the pty on A simply connects to system B
via
TCP and forwards any data from system B''s pty to system A''s
pty.  This
forwarding chains nicely (albiet naively) if the vm hops across multiple 
machines in a cluster without closing a console.  You could also be 
smarter and have system B signal system A to reconnect to system C if 
the vm is migrated from system B to system C.

Of course, the naive chaining allows your hopping to cross networks such 
that if system A and B are on one network, and B and C are on a 
different network, it all still works.

A cluster-aware toolchain could forward any new console requests 
directly to system B and the forwarded console would disappear once any 
clients still connected to A disconnect.

This is just one idea.  There may be a better way.

Regards,
Anthony Liguori
>I''d like to see a decent discussion of how best to do consoles
before
>changing the status quo. 
>
>Thanks,
>Ian 
>
>
> 
>
>  
>


-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content. 
Register
by 3/29 & save $300
http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Hi Ian,

On Wed, Mar 23, 2005 at 05:43:22PM -0000, Ian Pratt
wrote:
> > I chose 732 because it''s unassigned indeed.
> 
> Grabbing any port <1024 should do, there''s no need to just go
for 732,
> but have a series of ports that are tried. 
You did not read the patch :-)
xm tries all ports from 732 -- 1023 before it gives up and just uses
a random one.
> > If you have a patch, I''d volunteer to review :-)
> 
> For Xen 2.x, unix domain sockets would be too much of a pain to
> implement over Twisted. Kurt''s approach gets us closer toward
''secure by
> default''.
> 
> Xen 3 will be very different.
I have no clear picture yet of the control tools that we''ll have in 
Xen 3. If we''re still heading for release in summer, we should maket
some progress with redesigning if we really want to get rid of twisted.
Looking into it for just a few hours, I''m not so unhappy with twisted,
actually.
> > Before I start working on getting the consoles under control, I 
> > wanted to see whether this approach is acceptable at all.
> 
> I think it''s a good band-aid.
> 
> Perhaps a better way to handle consoles would be to use
''screend'', and
> then have incoming ssh connections dispatched to particular screen
> sessions.
screen is what is commonly used to handle many (mostly serial) consoles
these days, so hooking into that is certainly something most sysadmins
would consider a natural choice.
> > > 5) you still have to deal with xfrd
> > 
> > It seems to listen on *:8002 ... 
> > Is there no authentication either? Sigh.
> > 
> > And we probably need to look into the event channel (8001) as well.
> 
> Xfrd needs an option to listen only on localhost. (It''s still
needed for
> save/restore even if you don''t use migrate).
We could just pass it an option during startup.
> The event channel only ever needs to be localhost (and could probably be
> turned into a unix domain socket quite easily).
Sounds good. Let''s do it.

Regards,
-- 
Kurt Garloff                   <kurt@garloff.de>             [Koeln, DE]
Physics:Plasma modeling <garloff@plasimo.phys.tue.nl> [TU Eindhoven, NL]
Linux: SUSE Labs (Director)    <garloff@suse.de>            [Novell Inc]

On Wed, 23 Mar 2005 13:27:16 -0600, Anthony Liguori <aliguori@us.ibm.com>
wrote:
> Perhaps we could export the console via a pty and then create a screen
> session by executing the equivalent of "screen vm-console domid".
> 
> Clients can then connect to it by executing screen -x (instead of
> connecting directly to the pty) and our client could translate C-] to
> C-a C-d to detach from the screen.  Any reconnects will perserve the
> screen of the previous session.
Yes, I think this is what we want.  Although I thought we could
probably change screen''s keyboard mapping such that C-] is the escape
character and at the same time finally get support for sending C-] to
the domain -- I keep getting stuck in nested xencons clients...
You can have screen -x as a login shell or run it from command= in a
.ssh/authorized_keys file.
> This way, we can still have minimalistic toolchains that provide serial
> style consoles.
I think it should be an option in the domain configuration file
whether the domain creating tool should also setup a screen session
backing the console.  I think this needs to be somehow linked to the
domain creation tool because otherwise you won''t capture the entire
output.
If we support multiple consoles for a single domain, it would also be
nice to have them all connected to the same screen session, allowing
you to switch between the consoles using C-] 1, C-] 2, ...

   christian


-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content. 
Register
by 3/29 & save $300
http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

On Wed, Mar 23, 2005 at 06:51:00PM -0000, Ian Pratt
wrote:
> There are a couple of other issues that we should consider at the same
> time. I''ve heard a couple of users complain that they find our
model of
> exporting serial consoles confusing: when they quit a console session
> and reconnect they find that they are still logged in. 
They never used screen, apparently.
And this capability is actually one of the primary reasons why
many people do use screen. The multiplexing is secondary.

Rgeards,
-- 
Kurt Garloff, Director SUSE Labs, Novell Inc.

> > Perhaps a better way to handle consoles would be to use 
> ''screend'', and
> > then have incoming ssh connections dispatched to particular screen
> > sessions.
> 
> screen is what is commonly used to handle many (mostly 
> serial) consoles
> these days, so hooking into that is certainly something most sysadmins
> would consider a natural choice.
I think we''ve got resounding agreement on using screen.
 
> > > > 5) you still have to deal with xfrd
> > > 
> > > It seems to listen on *:8002 ... 
> > > Is there no authentication either? Sigh.
> > > 
> > > And we probably need to look into the event channel 
> (8001) as well.
> > 
> > Xfrd needs an option to listen only on localhost. (It''s 
> still needed for
> > save/restore even if you don''t use migrate).
> 
> We could just pass it an option during startup.
Yep, though it should be configurable from the xend config.
> > The event channel only ever needs to be localhost (and 
> could probably be
> > turned into a unix domain socket quite easily).
> 
> Sounds good. Let''s do it.
Keep those patches coming! :-)

Thanks,
Ian


-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content. 
Register
by 3/29 & save $300
http://ads.osdn.com/?ad_idh83&alloc_id149&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Hi,

On Wed, Mar 23, 2005 at 09:37:49PM +0000, Christian Limpach
wrote:
> If we support multiple consoles for a single domain, it would also be
> nice to have them all connected to the same screen session, allowing
> you to switch between the consoles using C-] 1, C-] 2, ...
With screen, you can at least connect multiple times to the same
console/session.
For the rest, screen inside screen will do :-)

Regards,
-- 
Kurt Garloff, Director SUSE Labs, Novell Inc.

Kurt Garloff wrote:
> Hi,
> 
> as discussed previously, I went ahead and introduced a setting that
> allows you to restrict the stuff you can when controlling xen by
> connecting to the port 8000 unless you connect from a privileged
> port.
I thought the consensus was to use Unix domain socket-based
restrictions for this?

-- 
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>



-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content. 
Register
by 3/29 & save $300
http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Ian Pratt wrote:
> For Xen 2.x, unix domain sockets would be too much of a pain to
> implement over Twisted. Kurt''s approach gets us closer toward
''secure by
> default''.
That just tells me you don''t know twisted
(putting my "Twisted upstream developer" hat on..)

Replace current reactor.listenTCP(port, protocolFactory)
with reactor.listenUNIX(path, protocolFactory).
If there''s code that assumes TCP things (transport.getPeer()
to give IP addresses and ports etc), those may need to be fixed,
naturally.

If you would use .tacs, as the recommended Twisted way
of deplying server applications is, that would more like
a configuration file change, done in /etc, as suits the admin.

If you would use strports, that would be switching from
string "8080" to string "unix:/path/to/socket".

The actual protocol mechanics work identically.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

On Thu, 2005-03-24 at 13:06, Tommi Virtanen wrote:
> Ian Pratt wrote:
> > For Xen 2.x, unix domain sockets would be too much of a pain to
> > implement over Twisted. Kurt''s approach gets us closer toward
''secure by
> > default''.
> 
> That just tells me you don''t know twisted
> (putting my "Twisted upstream developer" hat on..)
> 
> Replace current reactor.listenTCP(port, protocolFactory)
> with reactor.listenUNIX(path, protocolFactory).
> If there''s code that assumes TCP things (transport.getPeer()
> to give IP addresses and ports etc), those may need to be fixed,
> naturally.
Thanks, I couldn''t figure out why exporting the consoles over a domain
socket wasn''t working :-)  Turns out we''re using .getPeer().

I think perhaps we didn''t use twisted as best as we could have so I
agree with that it''s going to be a fair bit of work.

Regards,

-- 
Anthony Liguori
Linux Technology Center (LTC) - IBM Austin
E-mail: aliguori@us.ibm.com
Phone: (512) 838-1208




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel