---
www/manager/storage/ZFSPoolEdit.js | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/www/manager/storage/ZFSPoolEdit.js
b/www/manager/storage/ZFSPoolEdit.js
index dfefa0b..9ad1284 100644
--- a/www/manager/storage/ZFSPoolEdit.js
+++
Also , it seem that connection tracking is not implemented in bridge table
http://wiki.nftables.org/wiki-nftables/index.php/Bridge_filtering
- Mail original -
De: aderumier aderum...@odiso.com
À: Wolfgang Bumiller w.bumil...@proxmox.com
Cc: pve-devel pve-devel@pve.proxmox.com
Envoyé:
On Mon, Jul 27, 2015 at 03:01:30PM +0200, Alexandre DERUMIER wrote:
Oh, I speak too fast,
seem that for tcp traffic in bridge chain, I can see PROTO and port.
forward: IN=tap150i0 OUT=fwln150i0
MAC=00:08:7c:bd:ae:40:76:ef:e9:ed:9d:41:08:00 SRC=10.3.95.240
DST=192.168.100.76 LEN=108
I think Xbriport only ever works on bridge filters, (on current kernels,
too). Is there any reason to put it in the ip tables? You can still
match on `ip saddr`, `ip6 saddr`, `ip6 nexthdr` etc. in bridge filters.
I don't known why, but I don't see any traffic in forward from bridge table.
A patch exists to prevent a crash when a socket cannot be opened.
https://lists.gnu.org/archive/html/qemu-devel/2015-05/msg00577.html
Included in the current 2.4 devel build.
I've done some experimenting. If I take the KVM command as generated
by Proxmox and simply add -runas nobody the VM
Yes, that much I've tested, too. I'm worried about the shutdown scripts
though (bridgedown). They might lack permissions if qemu doesn't keep a
privileged parent process around for those.
I think that pci passthrough need root access too. (maybe not with vfio).
Not sure about disks with /dev/
Hi,
does this affect proxmox? I don't understand why xen is explicit content
of the advisory.
http://seclists.org/oss-sec/2015/q3/212
--
Stefan
___
pve-devel mailing list
pve-devel@pve.proxmox.com
I think Xbriport only ever works on bridge filters, (on current kernels,
too). Is there any reason to put it in the ip tables? You can still
match on `ip saddr`, `ip6 saddr`, `ip6 nexthdr` etc. in bridge filters.
Btw. I find the table syntax much more readable than command lists.
table bridge
Instead of a lot of hardcoded if's use JSONSchema::parse_config to
parse and validate vzdump.conf. To do that $confdesc was extended
to match a valid schema.
Signed-off-by: Thomas Lamprecht t.lampre...@proxmox.com
---
Changes since v2:
* use given PVE::Tools method to get file content
* relocate
I have no idea if CVE-2015-5154 that Stephan inquired about affests Proxmox.
But when I see exploits like that the first thought in my mind is how
easy it would be for such an exploit to get root on the Proxmox host.
I've done some experimenting. If I take the KVM command as generated
by Proxmox
oh ok, didn't known that. (still a bit confuse between bridge vs ip/inet
tables)
I'm new to nft, too, but as far as I understand it's not actually much
different from iptables (from the outside anyway).
It's just that rather than having several tools managing chains, you
have a single tool
Closes #303
---
www/manager/Utils.js | 2 +-
www/manager5/Utils.js | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/www/manager/Utils.js b/www/manager/Utils.js
index 351f157..0e2e8a2 100644
--- a/www/manager/Utils.js
+++ b/www/manager/Utils.js
@@ -166,7 +166,7 @@
On Mon, Jul 27, 2015 at 12:07:41PM +0200, Michael Rasmussen wrote:
On Mon, 27 Jul 2015 11:42:57 +0200
Wolfgang Bumiller w.bumil...@proxmox.com wrote:
The `= undef;` part shouldn't be necessary as that's implicit. We seem
to mostly leave it out in our code as far as I can tell.
This
Yes I think you can match almost everything in pretty much every table.
Provided they have implemented it ;-) so we'll have to wait for ct to
land in bridge tables before considering switching to nft.
Yes, we should wait.
Currently I'm just testing it, time to time, to see how it's evolving.)
Oh, I speak too fast,
seem that for tcp traffic in bridge chain, I can see PROTO and port.
forward: IN=tap150i0 OUT=fwln150i0
MAC=00:08:7c:bd:ae:40:76:ef:e9:ed:9d:41:08:00 SRC=10.3.95.240
DST=192.168.100.76 LEN=108 TOS=0x00 PREC=0x00 TTL=64 ID=42868 DF PROTO=TCP
SPT=22 DPT=49876 WINDOW=291
Updated debian package control files and Makefile
to build GFS2-3.1.8 for Proxmox VE 4.
We use the following sources to build GFS2:
https://git.fedorahosted.org/cgit/gfs2-utils.git/snapshot/gfs2-utils-3.1.8.tar.gz
Signed-off-by: Thomas Lamprecht t.lampre...@proxmox.com
---
Makefile | 6
you
have a single tool managing tables containing the chains. Iow. bridge
stuff still goes into the bridge tables, ip stuff into the ip tables,
arp stuff into the arp tables.
bridge log: (get forward working).
: IN=fwln150i0 OUT=tap150i0 ARP HTYPE=1 PTYPE=0x0800 OPCODE=1
to answer myself. PVE is affected. Every VM with a CDROM can get root.
Stefan
Am 27.07.2015 um 14:36 schrieb Stefan Priebe - Profihost AG:
Hi,
does this affect proxmox? I don't understand why xen is explicit content
of the advisory.
http://seclists.org/oss-sec/2015/q3/212
--
Stefan
Le 27/07/2015 15:29, Eric Blevins a écrit :
I have no idea if CVE-2015-5154 that Stephan inquired about affests Proxmox.
But when I see exploits like that the first thought in my mind is how
easy it would be for such an exploit to get root on the Proxmox host.
I've done some experimenting.
These patches update GFS2 to the actual stable version 3.1.8
and also update the debian package control files.
GFS2 sources used:
https://git.fedorahosted.org/cgit/gfs2-utils.git/snapshot/gfs2-utils-3.1.8.tar.gz
Thomas Lamprecht (2):
gfs2-utils: Fixed patches for updated GFS2
gfs2-utils:
we could create the tap interface,
tunctl -t tap0 -u myuser
then pass it to qemu without script
-netdev tap,ifname=tap0,id=mynet0,script=no
(and the bridge create, tap plug, could be also done manually in qemuserver
vmstart)
- Mail original -
De: aderumier aderum...@odiso.com
À:
to answer myself. PVE is affected. Every VM with a CDROM can get root.
yes, indeed :(
https://access.redhat.com/security/cve/CVE-2015-5154
- Mail original -
De: Stefan Priebe s.pri...@profihost.ag
À: pve-devel pve-devel@pve.proxmox.com
Envoyé: Lundi 27 Juillet 2015 15:39:54
Objet: Re:
Having only PCI passthrough VMs running as root would be a huge improvement.
Maybe cgroups could be used to reduce the risk.
Exit scripts could be suid if needed.
An exploted VM could potentially use the suid pve-bridgedown script to
destroy bridges of other VMs.
Long term I think a better idea
does somebody have tested my vlan bridges patches ? (note that that need
iproute2 from debian sid, for vlan ranges)
It's working really fine here, I'm looking to add a patch for Q-in-Q bridge
too. (I think Stefan Priebe use them)
- Mail original -
De: aderumier aderum...@odiso.com
Exit scripts could be suid if needed.
Scripts cannot be suid, because the executable is their interpreter, iow
/bin/sh, which
in turn is not setuid-root.
The exit scripts could simply notify some other privlidged process
that they are shutting down.
This is better. Even better would be a
On Wed, 22 Jul 2015 01:25:14 +0200
Michael Rasmussen m...@datanom.net wrote:
Hi all,
I have installed a proxmox 4.0 to test openvswitch and IMHO the current
network GUI config is not suited for the task since every time you need
to create or delete an OVSint Port a reboot of the node is
Hi all,
Why is it not possible to add a nic to a lxc CT using DHCP?
The reason I ask is because every time a lxc CT is restarted the
interfaces file is reset provided it is configured to use DHCP.
--
Hilsen/Regards
Michael Rasmussen
Get my public GnuPG keys:
michael at rasmussen dot cc
On Mon, 27 Jul 2015 18:29:32 +0200 (CEST)
Dietmar Maurer diet...@proxmox.com wrote:
AFAIK this is already possible with latest version from git.
Yes;-) When will the patch hit pvetest?
--
Hilsen/Regards
Michael Rasmussen
Get my public GnuPG keys:
michael at rasmussen dot cc
AFAIK this is already possible with latest version from git.
Yes;-) When will the patch hit pvetest?
I will try to upload this week.
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
I guess it would also help if we add a reasonable apparmor profile?
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Why is it not possible to add a nic to a lxc CT using DHCP?
The reason I ask is because every time a lxc CT is restarted the
interfaces file is reset provided it is configured to use DHCP.
AFAIK this is already possible with latest version from git.
I guess it would also help if we add a reasonable apparmor profile?
apparmor profiles would be greatly appreciated
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
eval {
ovs-vsctl add-port $bridge vlan$port tag=$port -- set interface
vlan$port type=internal
};
internal interface can have a random name.
also, we need to manage update. (ip modification for example).
we could do down, up . But it's not optimal.
- Mail original -
De:
On Mon, 27 Jul 2015 20:08:24 +0200 (CEST)
Alexandre DERUMIER aderum...@odiso.com wrote:
eval {
ovs-vsctl add-port $bridge vlan$port tag=$port -- set interface
vlan$port type=internal
};
internal interface can have a random name.
I know, but to keep it simple and IMHO more intuitive
A monitoring process which does not rely on events could potentially be
a resource hawk.
Well I wasn't suggesting a busy-waiting daemon. More like listening with
inotify on the qemu cgroup directory, since we use systemd-run to run VMs
in a scope now, this would allow an event-based
On Mon, 27 Jul 2015 20:11:54 +0200 (CEST)
Wolfgang Bumiller w.bumil...@proxmox.com wrote:
This is better. Even better would be a monitoring process that doesn't need to
be signaled.
(Coincidentally, this would also add the possibility of adding reliably-fired
exit-time hooks.)
A
A document is already describing something similar.
http://docs.ganeti.org/ganeti/2.13/html/design-kvmd.html
I always tried to avoid that.
We can still use a shutdown script, but it needs to be something
that can be compiled in order to get the necessary capabilities.
Hmm, what's actually
When can we expect a fix in pvetest repositories?
--
Fügen Sie uns in die Liste vertrauenswürdiger Absender hinzu.
If you have any further questions, please let us know.
Mit freundlichen Grüßen / With best regards
myVirtualserver.de | Development Team
Henry Spanka
I think the best option is to run every KVM as another user and chown
the /var/lib/vz/images/VMID/ directory to that user.
There will be vulnerabilities at any time and the best option is to
just use other users to prevent execution of code on the host or
modify other vms(read data).
Best
On Mon, 27 Jul 2015 11:42:57 +0200
Wolfgang Bumiller w.bumil...@proxmox.com wrote:
The `= undef;` part shouldn't be necessary as that's implicit. We seem
to mostly leave it out in our code as far as I can tell.
This is a legacy for all old Perl coders back from the days where
variables
Hi,
I have done a small test with nftables 0.4 (from debian sid) + kernel 3.19,
modprobe nf_tables
modprobe nf_tables_ipv4
modprobe nft_meta_bridge
nft list ruleset
nft flush table inet filter
nft add table inet filter
nft add chain inet filter forward { type filter hook forward priority 0 \;
When can we expect a fix in pvetest repositories?
its already there (pvetest and pve-no-subscription) - please test.
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
we have done it for lxc container.
https://git.proxmox.com/?p=pve-container.git;a=blob_plain;f=src/PVE/LXC.pm;hb=HEAD
sub update_ipconfig {}
What I would like to do, is when in gui we have done the new config in
/etc/network/interfaces.new,
then apply it online.
So manage dependencies
Now that we have qemu 2.4,
I think we can apply this patch ?
- Mail original -
De: aderumier aderum...@odiso.com
À: pve-devel pve-devel@pve.proxmox.com
Cc: aderumier aderum...@odiso.com
Envoyé: Mercredi 1 Juillet 2015 17:37:23
Objet: [PATCH] add memory_unplug support
qemu 2.4 feature
Am 27.07.2015 um 20:27 schrieb Michael Rasmussen m...@datanom.net:
On Mon, 27 Jul 2015 20:08:24 +0200 (CEST)
Alexandre DERUMIER aderum...@odiso.com wrote:
eval {
ovs-vsctl add-port $bridge vlan$port tag=$port -- set interface
vlan$port type=internal
};
internal interface can have a
about linux bridge vs ovs performance, I have found an good presentation from
redhat.
https://www.youtube.com/watch?v=MbBX_J5zR4w
to resume, linux bridge is a little bit faster than ovs.
But with coming ovs dpdk support, performance will be 5x faster for small
packets an single flow.
(But
---
...reboot-flag-and-delete-old-veth-on-reboot.patch | 34 --
1 file changed, 19 insertions(+), 15 deletions(-)
diff --git
a/debian/patches/0001-pass-on-reboot-flag-and-delete-old-veth-on-reboot.patch
applied, thanks.
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
applied.
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
-my $res = {
+my $defaults = {
(...)
+foreach my $key (keys %$defaults) {
+ $res-{$key} = $defaults-{$key} if !$res-{$key};
+}
I wonder if this is actually even necessary as parse_config should
simply override old keys.
+ local $/ = undef;
The `= undef;` part
Instead of a lot of hardcoded if's use JSONSchema::parse_config to
parse and validate vzdump.conf. To do that $confdesc was extended
to match a valid schema.
Signed-off-by: Thomas Lamprecht t.lampre...@proxmox.com
---
PVE/VZDump.pm | 58 +-
51 matches
Mail list logo
