FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 08-06-2012, 11:24 PM
Andrea Scarpino
 
Default

Hi all,
the new KDE major release[1] has been moved to [extra].
Read the upstream changelog for the new features/bug fixes.

The KDE Multimedia development has been moved to git. As consequence of this,
the kdemultimedia-kioslave package has been removed and split into:
* kdemultimedia-audiocd-kio
* libkcddb
* libkcompactdisc

Every maintainer of the packages depending on the -kioslave package should
check the dependencies.

Also libkipi, libkexiv2 and libdcraw packages have a soname bump,
respectively:
libkipi.so.8 -> libkipi.so.9
libkdcraw.so.20 -> libkdcraw.so.21
libkexiv2.so.10 -> libkexiv2.so.11
The packages in the official repos have been rebuilt.

The kdesdk-kdeaccounts-plugin, kdesdk-kdepalettes and kdeutils-ksecrets
packages have been removed.

Have a nice update!

[1] http://kde.org/announcements/4.9/

--
Andrea
 
Old 08-07-2012, 08:07 AM
Arch Website Notification
 
Default

=== Signoff report for [testing] ===
https://www.archlinux.org/packages/signoffs/

There are currently:
* 4 new packages in last 24 hours
* 0 known bad packages
* 0 packages not accepting signoffs
* 9 fully signed off packages
* 28 packages missing signoffs
* 2 packages older than 14 days

(Note: the word 'package' as used here refers to packages as grouped by
pkgbase, architecture, and repository; e.g., one PKGBUILD produces one
package per architecture, even if it is a split package.)


== New packages in [testing] in last 24 hours (4 total) ==

* nvidia-304.32-2 (i686)
* nvidia-lts-304.32-2 (i686)
* nvidia-304.32-2 (x86_64)
* nvidia-lts-304.32-2 (x86_64)


== Incomplete signoffs for [core] (9 total) ==

* dhcpcd-5.6.0-1 (i686)
1/2 signoffs
* iproute2-3.5.0-1 (i686)
0/2 signoffs
* linux-lts-3.0.39-1 (i686)
0/2 signoffs
* logrotate-3.8.2-1 (i686)
1/2 signoffs
* net-tools-1.60.20120804git-1 (i686)
0/2 signoffs
* iproute2-3.5.0-1 (x86_64)
0/2 signoffs
* linux-lts-3.0.39-1 (x86_64)
1/2 signoffs
* logrotate-3.8.2-1 (x86_64)
0/2 signoffs
* net-tools-1.60.20120804git-1 (x86_64)
0/2 signoffs

== Incomplete signoffs for [extra] (19 total) ==

* dri2proto-2.8-1 (any)
0/2 signoffs
* randrproto-1.4.0-1 (any)
0/2 signoffs
* kdeplasma-applets-networkmanagement-1:0.9.0.4-1 (i686)
0/2 signoffs
* libxrandr-1.4.0-1 (i686)
0/2 signoffs
* lirc-1:0.9.0-25 (i686)
0/2 signoffs
* monodevelop-3.0.3.5-2 (i686)
0/2 signoffs
* monodevelop-debugger-gdb-3.0.3.5-1 (i686)
0/2 signoffs
* nvidia-304.32-2 (i686)
0/2 signoffs
* nvidia-lts-304.32-2 (i686)
0/2 signoffs
* openconnect-1:4.00-1 (i686)
0/2 signoffs
* xf86-video-intel-2.20.3-1 (i686)
0/2 signoffs
* libxrandr-1.4.0-1 (x86_64)
0/2 signoffs
* lirc-1:0.9.0-25 (x86_64)
0/2 signoffs
* monodevelop-3.0.3.5-2 (x86_64)
0/2 signoffs
* monodevelop-debugger-gdb-3.0.3.5-1 (x86_64)
0/2 signoffs
* nvidia-304.32-2 (x86_64)
0/2 signoffs
* nvidia-lts-304.32-2 (x86_64)
0/2 signoffs
* openconnect-1:4.00-1 (x86_64)
1/2 signoffs
* xf86-video-intel-2.20.3-1 (x86_64)
1/2 signoffs


== Completed signoffs (9 total) ==

* initscripts-2012.08.1-1 (any)
* e2fsprogs-1.42.5-1 (i686)
* iptables-1.4.15-1 (i686)
* linux-3.5-2 (i686)
* dhcpcd-5.6.0-1 (x86_64)
* e2fsprogs-1.42.5-1 (x86_64)
* iptables-1.4.15-1 (x86_64)
* linux-3.5-2 (x86_64)
* kdeplasma-applets-networkmanagement-1:0.9.0.4-1 (x86_64)


== All packages in [testing] for more than 14 days (2 total) ==

* openconnect-1:4.00-1 (i686), since 2012-06-21
* openconnect-1:4.00-1 (x86_64), since 2012-06-21


== Top five in signoffs in last 24 hours ==

1. tomegun - 6 signoffs
2. allan - 2 signoffs
 
Old 08-07-2012, 08:07 AM
Arch Website Notification
 
Default

=== Signoff report for [community-testing] ===
https://www.archlinux.org/packages/signoffs/

There are currently:
* 0 new packages in last 24 hours
* 0 known bad packages
* 0 packages not accepting signoffs
* 0 fully signed off packages
* 22 packages missing signoffs
* 0 packages older than 14 days

(Note: the word 'package' as used here refers to packages as grouped by
pkgbase, architecture, and repository; e.g., one PKGBUILD produces one
package per architecture, even if it is a split package.)



== Incomplete signoffs for [community] (20 total) ==

* systemd-arch-units-20120704-2 (any)
0/2 signoffs
* cdfs-2.6.27-26 (i686)
0/2 signoffs
* ndiswrapper-1.57-18 (i686)
0/2 signoffs
* open-vm-tools-modules-2012.05.21-6 (i686)
0/2 signoffs
* r8168-8.031.00-9 (i686)
0/2 signoffs
* r8168-lts-8.031.00-4 (i686)
0/2 signoffs
* rt3562sta-2.4.1.1-12 (i686)
0/2 signoffs
* slmodem-2.9.11-67 (i686)
0/2 signoffs
* vhba-module-20120422-6 (i686)
0/2 signoffs
* virtualbox-modules-4.1.18-6 (i686)
0/2 signoffs
* virtualbox-modules-lts-4.1.18-4 (i686)
0/2 signoffs
* cdfs-2.6.27-26 (x86_64)
0/2 signoffs
* ndiswrapper-1.57-18 (x86_64)
0/2 signoffs
* open-vm-tools-modules-2012.05.21-6 (x86_64)
0/2 signoffs
* r8168-8.031.00-9 (x86_64)
0/2 signoffs
* r8168-lts-8.031.00-4 (x86_64)
0/2 signoffs
* rt3562sta-2.4.1.1-12 (x86_64)
0/2 signoffs
* vhba-module-20120422-6 (x86_64)
0/2 signoffs
* virtualbox-modules-4.1.18-6 (x86_64)
0/2 signoffs
* virtualbox-modules-lts-4.1.18-4 (x86_64)
0/2 signoffs

== Incomplete signoffs for [unknown] (2 total) ==

* tp_smapi-0.41-5 (i686)
0/2 signoffs
* tp_smapi-0.41-5 (x86_64)
0/2 signoffs


== Top five in signoffs in last 24 hours ==

1. tomegun - 6 signoffs
2. allan - 2 signoffs
 
Old 08-07-2012, 01:47 PM
Celejar
 
Default

On Fri, 3 Aug 2012 00:59:08 +0300
Andrei POPESCU <andreimpopescu@gmail.com> wrote:

> On Mi, 01 aug 12, 20:23:35, Celejar wrote:
> > On Wed, 1 Aug 2012 19:45:27 +0300
> > Andrei POPESCU <andreimpopescu@gmail.com> wrote:
> >
> > > On Mi, 01 aug 12, 00:59:29, Yaro Kasear wrote:
> > > > On 07/31/2012 01:42 PM, Celejar wrote:
> > > > >On Fri, 20 Jul 2012 10:30:50 +0300
> > > > >Andrei POPESCU<andreimpopescu@gmail.com> wrote:
> > > > >
> > > > >>On Jo, 19 iul 12, 22:50:25, Celejar wrote:
> > > > >>>Quite true - and completely irrelevant to my point. I don't deny that
> > > > >>>money can be made with FLOSS, just that it's pointless to try to sell
> > > > >>>copies of one's software if it's freely copyable. The examples you give
> > > > >>>are all of models other than the straightforward sale of licenses or
> > > > >>>copies.
> > > > >>IMO a business model that relies on the possibility to sell copies that
> > > > >>basically cost nothing to produce is broken.
> > > > >Is this a moral claim, a business one, a legal one, or just plain dogma?
> >
> > [The line to which you are responding is mine, not Yaro's.]
>
> Yes I know, and I thought the levels of quoting show that, or don't
> they?

They do - but the first quote in your message was Yaro's. I guess you
decided to respond to a quote of mine as cited in his email, instead of
responding directly to my email. In such a case, I generally delete the
first name in the chain, but I admit that I don't know if that's the
Right Way To Do It.

Celejar


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120807094711.e73ff992.celejar@gmail.com">http://lists.debian.org/20120807094711.e73ff992.celejar@gmail.com
 
Old 08-07-2012, 02:34 PM
Steve
 
Default

Hi Ted,

---- Ted Miller <tedlists@sbcglobal.net> wrote:
> On 08/06/2012 02:57 PM, Steve wrote:
> > I'm running an up-to-date CentOS 6 virtual machine in a VMWare player on a Windows box and
> > I cannot set the display resolution to anything higher than 1280x720.
> Windows shows the
> > screen resolution on this monitor to be 1920x1080.
> > I do have VMWareTools installed although I'm not certain it is installed correctly. How can I tell?

>
> Looks like you may need to rebuild or download VMWareTools for your latest
> kernel upgrade, but that may not deal with your basic problem.
>
> The vmwlegacy video driver is located in the xorg-x11-drv-vmware package
> that Centos provides in the "base" repository. You probably need to
> install, update, or re-install that package.
>
> Ted Miller

I do have the xorg-x11-drv-vmware package insalled:

$ rpm -qa | grep vmware
xorg-x11-drv-vmware-11.0.3-1.el6.i686

$ rpm -q --provides xorg-x11-drv-vmware-11.0.3-1.el6.i686
vmware_drv.so
vmwlegacy_drv.so
xorg-x11-drv-vmware = 11.0.3-1.el6
xorg-x11-drv-vmware(x86-32) = 11.0.3-1.el6

$ locate vmwlegacy_drv.so
/usr/lib/vmware-tools/configurator/...<about 10 different versions>
/usr/lib/xorg/modules/drivers/vmlegacy_drv.so.old.0

Interesting. Why is the driver called .old.0?

# yum reinstall xorg-x11-drv-vmware-11.0.3-1.el6.i686
...
# ls /usr/lib/xorg/modules/drivers/vm*
/usr/lib/xorg/modules//drivers//vmware_drv.so
/usr/lib/xorg/modules//drivers//vmware_drv.so.BeforeVMwareToolsInstall.old.0
/usr/lib/xorg/modules//drivers//vmwlegacy_drv.so
/usr/lib/xorg/modules//drivers//vmwlegacy_drv.so.old.0

Reboot and ... yeay! Full screen resolution.

Thanks, Ted.

Steve
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 08-07-2012, 03:01 PM
"Serge E. Hallyn"
 
Default

(Hopefully my unsubscribed account can email kernel-team)

Hi,

this patch will probably not hit upstream, because the 'proper' fix is
user namespaces. User namespaces however won't be ready until after
quantal. So I'd like this patch to be applied in precise and quantal
if possible.

Problem:

Containers are granted CAP_SYS_BOOT. The reboot path in the kernel checks
whether you are in the initial pidns, and, if not, sends a signal to your
parent indicating you were 'rebooted' or 'shut down'. So there is no
danger of a container rebooting the host.

However, CAP_SYS_BOOT also authorized kexec, without the pidns check.
Therefore, containers are able to kexec a new kernel, which is obviously
a bad thing.

This patch prevents that by only allowing kexec from the initial pid
namespace. It is nacked by Eric Biederman (but acked by me) because
he feels this should be stopped by having the container in a private
user namespace, with the kexec cap_sys_boot check targeted to the initial
user namespace. As I said, that won't be doable during quantal timeframe.

thanks,
-serge

----- Forwarded message from "Daniel P. Berrange" <berrange@redhat.com> -----

Date: Fri, 3 Aug 2012 11:53:04 +0100
From: "Daniel P. Berrange" <berrange@redhat.com>
To: linux-kernel@vger.kernel.org
Cc: containers@lists.linux-foundation.org,
"Daniel P. Berrange" <berrange@redhat.com>,
Serge Hallyn <serge.hallyn@canonical.com>,
Daniel Lezcano <daniel.lezcano@free.fr>,
Michael Kerrisk <mtk.manpages@gmail.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Tejun Heo <tj@kernel.org>, Oleg Nesterov <oleg@redhat.com>
Subject: [PATCH] Forbid invocation of kexec_load() outside initial PID namespace

From: "Daniel P. Berrange" <berrange@redhat.com>

The following commit

commit cf3f89214ef6a33fad60856bc5ffd7bb2fc4709b
Author: Daniel Lezcano <daniel.lezcano@free.fr>
Date: Wed Mar 28 14:42:51 2012 -0700

pidns: add reboot_pid_ns() to handle the reboot syscall

introduced custom handling of the reboot() syscall when invoked
from a non-initial PID namespace. The intent was that a process
in a container can be allowed to keep CAP_SYS_BOOT and execute
reboot() to shutdown/reboot just their private container, rather
than the host.

Unfortunately the kexec_load() syscall also relies on the
CAP_SYS_BOOT capability. So by allowing a container to keep
this capability to safely invoke reboot(), they mistakenly
also gain the ability to use kexec_load(). The solution is
to make kexec_load() return -EPERM if invoked from a PID
namespace that is not the initial namespace

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Cc: Serge Hallyn <serge.hallyn@canonical.com>
Cc: Daniel Lezcano <daniel.lezcano@free.fr>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Oleg Nesterov <oleg@redhat.com>
---
kernel/kexec.c | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/kernel/kexec.c b/kernel/kexec.c
index 0668d58..b152bde 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -947,6 +947,11 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments,
if (!capable(CAP_SYS_BOOT))
return -EPERM;

+ /* Processes in containers must not be allowed to load a new
+ * kernel, even if they have CAP_SYS_BOOT */
+ if (task_active_pid_ns(current) != &init_pid_ns)
+ return -EPERM;
+
/*
* Verify we have a legal set of flags
* This leaves us room for future extensions.
--
1.7.11.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

----- End forwarded message -----

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 08-07-2012, 03:04 PM
Stéphane Graber
 
Default

On 08/07/2012 11:01 AM, Serge E. Hallyn wrote:
> (Hopefully my unsubscribed account can email kernel-team)
>
> Hi,
>
> this patch will probably not hit upstream, because the 'proper' fix is
> user namespaces. User namespaces however won't be ready until after
> quantal. So I'd like this patch to be applied in precise and quantal
> if possible.
>
> Problem:
>
> Containers are granted CAP_SYS_BOOT. The reboot path in the kernel checks
> whether you are in the initial pidns, and, if not, sends a signal to your
> parent indicating you were 'rebooted' or 'shut down'. So there is no
> danger of a container rebooting the host.
>
> However, CAP_SYS_BOOT also authorized kexec, without the pidns check.
> Therefore, containers are able to kexec a new kernel, which is obviously
> a bad thing.
>
> This patch prevents that by only allowing kexec from the initial pid
> namespace. It is nacked by Eric Biederman (but acked by me) because
> he feels this should be stopped by having the container in a private
> user namespace, with the kexec cap_sys_boot check targeted to the initial
> user namespace. As I said, that won't be doable during quantal timeframe.
>
> thanks,
> -serge

Sounds reasonable to include that one as we've been including Daniel
Lezcano's reboot patch in 12.04, that's just making things consistent
and fixing a pretty serious security hole in our usually fairly secure
defaults for containers in 12.04 and 12.10.

> ----- Forwarded message from "Daniel P. Berrange" <berrange@redhat.com> -----
>
> Date: Fri, 3 Aug 2012 11:53:04 +0100
> From: "Daniel P. Berrange" <berrange@redhat.com>
> To: linux-kernel@vger.kernel.org
> Cc: containers@lists.linux-foundation.org,
> "Daniel P. Berrange" <berrange@redhat.com>,
> Serge Hallyn <serge.hallyn@canonical.com>,
> Daniel Lezcano <daniel.lezcano@free.fr>,
> Michael Kerrisk <mtk.manpages@gmail.com>,
> "Eric W. Biederman" <ebiederm@xmission.com>,
> Tejun Heo <tj@kernel.org>, Oleg Nesterov <oleg@redhat.com>
> Subject: [PATCH] Forbid invocation of kexec_load() outside initial PID namespace
>
> From: "Daniel P. Berrange" <berrange@redhat.com>
>
> The following commit
>
> commit cf3f89214ef6a33fad60856bc5ffd7bb2fc4709b
> Author: Daniel Lezcano <daniel.lezcano@free.fr>
> Date: Wed Mar 28 14:42:51 2012 -0700
>
> pidns: add reboot_pid_ns() to handle the reboot syscall
>
> introduced custom handling of the reboot() syscall when invoked
> from a non-initial PID namespace. The intent was that a process
> in a container can be allowed to keep CAP_SYS_BOOT and execute
> reboot() to shutdown/reboot just their private container, rather
> than the host.
>
> Unfortunately the kexec_load() syscall also relies on the
> CAP_SYS_BOOT capability. So by allowing a container to keep
> this capability to safely invoke reboot(), they mistakenly
> also gain the ability to use kexec_load(). The solution is
> to make kexec_load() return -EPERM if invoked from a PID
> namespace that is not the initial namespace
>
> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
> Cc: Serge Hallyn <serge.hallyn@canonical.com>
> Cc: Daniel Lezcano <daniel.lezcano@free.fr>
> Cc: Michael Kerrisk <mtk.manpages@gmail.com>
> Cc: "Eric W. Biederman" <ebiederm@xmission.com>
> Cc: Tejun Heo <tj@kernel.org>
> Cc: Oleg Nesterov <oleg@redhat.com>
> ---
> kernel/kexec.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index 0668d58..b152bde 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -947,6 +947,11 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments,
> if (!capable(CAP_SYS_BOOT))
> return -EPERM;
>
> + /* Processes in containers must not be allowed to load a new
> + * kernel, even if they have CAP_SYS_BOOT */
> + if (task_active_pid_ns(current) != &init_pid_ns)
> + return -EPERM;
> +
> /*
> * Verify we have a legal set of flags
> * This leaves us room for future extensions.
>


--
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 08-07-2012, 05:03 PM
Andy Whitcroft
 
Default

On Tue, Aug 07, 2012 at 11:04:37AM -0400, Stéphane Graber wrote:
> On 08/07/2012 11:01 AM, Serge E. Hallyn wrote:
> > (Hopefully my unsubscribed account can email kernel-team)
> >
> > Hi,
> >
> > this patch will probably not hit upstream, because the 'proper' fix is
> > user namespaces. User namespaces however won't be ready until after
> > quantal. So I'd like this patch to be applied in precise and quantal
> > if possible.
> >
> > Problem:
> >
> > Containers are granted CAP_SYS_BOOT. The reboot path in the kernel checks
> > whether you are in the initial pidns, and, if not, sends a signal to your
> > parent indicating you were 'rebooted' or 'shut down'. So there is no
> > danger of a container rebooting the host.
> >
> > However, CAP_SYS_BOOT also authorized kexec, without the pidns check.
> > Therefore, containers are able to kexec a new kernel, which is obviously
> > a bad thing.
> >
> > This patch prevents that by only allowing kexec from the initial pid
> > namespace. It is nacked by Eric Biederman (but acked by me) because
> > he feels this should be stopped by having the container in a private
> > user namespace, with the kexec cap_sys_boot check targeted to the initial
> > user namespace. As I said, that won't be doable during quantal timeframe.
> >
> > thanks,
> > -serge
>
> Sounds reasonable to include that one as we've been including Daniel
> Lezcano's reboot patch in 12.04, that's just making things consistent
> and fixing a pretty serious security hole in our usually fairly secure
> defaults for containers in 12.04 and 12.10.

What an utter utter mess namespaces are.

> > ----- Forwarded message from "Daniel P. Berrange" <berrange@redhat.com> -----
> >
> > Date: Fri, 3 Aug 2012 11:53:04 +0100
> > From: "Daniel P. Berrange" <berrange@redhat.com>
> > To: linux-kernel@vger.kernel.org
> > Cc: containers@lists.linux-foundation.org,
> > "Daniel P. Berrange" <berrange@redhat.com>,
> > Serge Hallyn <serge.hallyn@canonical.com>,
> > Daniel Lezcano <daniel.lezcano@free.fr>,
> > Michael Kerrisk <mtk.manpages@gmail.com>,
> > "Eric W. Biederman" <ebiederm@xmission.com>,
> > Tejun Heo <tj@kernel.org>, Oleg Nesterov <oleg@redhat.com>
> > Subject: [PATCH] Forbid invocation of kexec_load() outside initial PID namespace
> >
> > From: "Daniel P. Berrange" <berrange@redhat.com>
> >
> > The following commit
> >
> > commit cf3f89214ef6a33fad60856bc5ffd7bb2fc4709b
> > Author: Daniel Lezcano <daniel.lezcano@free.fr>
> > Date: Wed Mar 28 14:42:51 2012 -0700
> >
> > pidns: add reboot_pid_ns() to handle the reboot syscall
> >
> > introduced custom handling of the reboot() syscall when invoked
> > from a non-initial PID namespace. The intent was that a process
> > in a container can be allowed to keep CAP_SYS_BOOT and execute
> > reboot() to shutdown/reboot just their private container, rather
> > than the host.
> >
> > Unfortunately the kexec_load() syscall also relies on the
> > CAP_SYS_BOOT capability. So by allowing a container to keep
> > this capability to safely invoke reboot(), they mistakenly
> > also gain the ability to use kexec_load(). The solution is
> > to make kexec_load() return -EPERM if invoked from a PID
> > namespace that is not the initial namespace
> >
> > Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
> > Cc: Serge Hallyn <serge.hallyn@canonical.com>
> > Cc: Daniel Lezcano <daniel.lezcano@free.fr>
> > Cc: Michael Kerrisk <mtk.manpages@gmail.com>
> > Cc: "Eric W. Biederman" <ebiederm@xmission.com>
> > Cc: Tejun Heo <tj@kernel.org>
> > Cc: Oleg Nesterov <oleg@redhat.com>
> > ---
> > kernel/kexec.c | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/kernel/kexec.c b/kernel/kexec.c
> > index 0668d58..b152bde 100644
> > --- a/kernel/kexec.c
> > +++ b/kernel/kexec.c
> > @@ -947,6 +947,11 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments,
> > if (!capable(CAP_SYS_BOOT))
> > return -EPERM;
> >
> > + /* Processes in containers must not be allowed to load a new
> > + * kernel, even if they have CAP_SYS_BOOT */
> > + if (task_active_pid_ns(current) != &init_pid_ns)
> > + return -EPERM;
> > +
> > /*
> > * Verify we have a legal set of flags
> > * This leaves us room for future extensions.
> >

Patch looks like a reasonable tightening of the rules given our other
patches.

Acked-by: Andy Whitcroft <apw@canonical.com>

-apw

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 08-07-2012, 05:45 PM
Andrei POPESCU
 
Default

On Ma, 07 aug 12, 09:47:11, Celejar wrote:
>
> They do - but the first quote in your message was Yaro's. I guess you
> decided to respond to a quote of mine as cited in his email, instead of
> responding directly to my email. In such a case, I generally delete the
> first name in the chain, but I admit that I don't know if that's the
> Right Way To Do It.

But I was responding to Yaro as well, otherwise I would have written two
separate e-mails.

Kind regards,
Andrei
--
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
 
Old 08-07-2012, 10:43 PM
Celejar
 
Default

On Tue, 7 Aug 2012 20:45:33 +0300
Andrei POPESCU <andreimpopescu@gmail.com> wrote:

> On Ma, 07 aug 12, 09:47:11, Celejar wrote:
> >
> > They do - but the first quote in your message was Yaro's. I guess you
> > decided to respond to a quote of mine as cited in his email, instead of
> > responding directly to my email. In such a case, I generally delete the
> > first name in the chain, but I admit that I don't know if that's the
> > Right Way To Do It.
>
> But I was responding to Yaro as well, otherwise I would have written two
> separate e-mails.

Okay, sorry.

Celejar


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120807184344.b352f416.celejar@gmail.com">http://lists.debian.org/20120807184344.b352f416.celejar@gmail.com
 

Thread Tools




All times are GMT. The time now is 05:56 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org