On Thu, Jul 06, 2006 at 06:44:12PM +0200, Robert Michel wrote:
> Salve Herbert!
>
> Herbert Poetzl schrieb am Donnerstag, den 06. Juli 2006 um 13:10h:
>
> > > but on the next day /usr/sbin/safe_asterisk does
> > > not found /dev/tty9..... /dev/pts/31 exist only
> > > for my bash, after exiting this bash, also
> > > /dev/pts/31 has been gone, and so this "hack"
> > > does not work... ;(
> >
> > precisely, either you _want_ that output to go
> > somewhere, then you have to 'provide' a real vc
> > terminal or to make asterisk 'create' it on startup
> > (by requesting a new one, like e.g. screen does)
>
> Exactly.
>
> > you could, for example, use screen to provide that
> > pseudo terminal without modifying asterisk
>
> I have to play more with screen/dtach
> - could screen create performance or other problems?
> IMHO does screen does much more than to just create
> a pseudo terminal and to slow asterik significant.
>
> > better use /dev/vc/9 (c:4:9 or the udev equiv) but
> > basically you 'could' create the device for the guest
> > on the host side, and the guest will be able to use
> > it, just be careful _what_ you give to your guests :)
>
> > > So root@guest can indirectly create dumy devices
> > > and there is still no tool like mknode for vserver
> > > - because it is not so neccessary and does not
> > > have such a high priority - right?
> >
> > no,
> > because it is a big can of worms and a security
> > issue, just imagine somebody creating a block device
> > which 'accidentially' is identical to your host's
> > root partition, and then starts modifying stuff at
> > a very low level :)
>
> You mean root@guest23 could do things with the
> power of root@host?
>
> I can understand that it is good that root@guest23
> can't dump the RAM, read the bios etc...
> and everybody who setup his own vserver is happy
> about a securiy gain - but it is a bit different
> for people who rent a vserver and are only
> root@guest.
>
> BTW I'm in favor that by default every vserver
> installation creates a Vserver-README inside
> the root directory for every guest instance
> and a vserver-root@guest-HowTo.
I agree, and this could be something the community
provides to the actual 'providers', but, as they
build their own environments, with a multitude of
different tools, there is no real way to 'force'
that into a guest (which IMHO would be wrong anyways)
> ISP are promoting vserver with "full root
> access" As far as I know yet root-guest
> can't use:
> iptables,
this one is not yet possible without help from the
provider, but some provers allow you to do that via
some web interface (in a secure way)
> ping,
should work quite fine with all recent versions of
Linux-VServer if the proper context capability is
set (raw_icmp, see http://linux-vserver.org/Caps+and+Flags)
> tracerout,
traceroute is a very misguided tool, and can be
replaced by (the much newer) tracepath which should
work out of the box (and give more information)
> ntp,
ntp uses the linux kernel to keep track of the time
which doesn't really make sense on a per guest basis,
it is much better to have only a single ntpd instance
on the host (or in a special time guest) which keeps
the entire system in sync
> mknod
is disabled (via a capability) for security reasons
as you do not want folks to mess with devices they
do not own ...
> so some misunderstandings or noise on mailinglist
> will come automaticaly.
yes, from a 'customer' point of view it is completely
understandable
> When I know more about vservers, I will try
> to contribute in that way...
>
> But back to the topic "could root@guest use mknod".
> Theoreticaly would it possible to add this feature
> with a vmknode and a tool for root@host that guest
> could create a block devices of their own without
> harming other guests or the host itself
> but it seems not to be a planed feature for vserver.
well, what kind of 'devices' would you like to
create inside a guest?
> It's unthankful that people asking everytime
> about errors or thinks that are not supported
no problem with that, all the issues and/or feature
requests reported back will be considered, and if
there is a good way to do it, we will probably add
it in the next version (as we already did with many
inspired features, like the per guest time base :)
> But I'm thankful about the vserver project
> and that you have the focus on security
you're very welcome!
best,
Herbert
> Greetings,
> rob
>
> _______________________________________________
> Vserver mailing list
> Vserver@list.linux-vserver.org
> http://list.linux-vserver.org/mailman/listinfo/vserver
_______________________________________________
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
Received on Fri Jul 7 16:31:13 2006