-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrew Morgan wrote:
>> +current->cap_effective = cap_intersect(current->cap_effective,
>> +current->cap_bset);
>> +current->cap_permitted = cap_intersect(current->cap_permitted,
>> +current->cap_bset);
>> +current->
This patch allows LSM modules filter incoming connections/datagrams
based on the process's security context who is attempting to pick up.
There are already hooks to filter incoming connections/datagrams
based on the socket's security context, but these hooks are not
applicable when one wants to do
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
> Andrew, this version follows all of your suggestions. Definately nicer
> userspace interface. thanks
[...]
>
> /* Allow ioperm/iopl access */
> @@ -314,6 +314,10 @@ typedef struct kernel_cap_struct {
>
> #define CAP_SETF
Quoting Andrew Morgan ([EMAIL PROTECTED]):
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Andrew,
>
> The attached patch (171282b3553fcec43b9ab615eb7daf6c2b494a87) applies
> against 2.6.24-rc2-mm1. It addresses the problem reported by Kevin and
> Andy - ultimately, the legacy support wasn'
On Tue, 20 Nov 2007, Tetsuo Handa wrote:
> Hello.
>
> Paul Moore wrote:
> > My apologies, I mistakenly read the following if statement in your patch:
> >
> > + if (skb == skb_peek(&sk->sk_receive_queue)) {
> > + __skb_unlink(skb, &sk->sk_receive_queue);
> > +
Hello.
Paul Moore wrote:
> My apologies, I mistakenly read the following if statement in your patch:
>
> + if (skb == skb_peek(&sk->sk_receive_queue)) {
> + __skb_unlink(skb, &sk->sk_receive_queue);
> + atomic_dec(&skb->users);
> + }
>
> I read the con
Quoting Chris Friedhoff ([EMAIL PROTECTED]):
> Hello Serge,
>
> just to let you know: with 2.6.24-rc3 I have the same problem.
Ok, so here is the flow.
First off, using runlevel 5 on FC7, using 'log out' correctly brings
you back to a new login prompt. Your problem is starting in runlevel
3, an
Andrew, this version follows all of your suggestions. Definately nicer
userspace interface. thanks
-serge
>From b7c210160e3c210d63eca532289ca1c9caf1bd87 Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn <[EMAIL PROTECTED]>
Date: Mon, 19 Nov 2007 13:54:05 -0500
Subject: [PATCH 1/1] capabilities: in
On Monday 19 November 2007 9:29:52 am Tetsuo Handa wrote:
> Paul Moore wrote:
> > If that is the case then the second call to
> > skb_peek() will return a different skb then the one you passed to
> > security_post_recv_datagram().
>
> Yes. The second call to skb_peek() might return a different skb
Hello.
Paul Moore wrote:
> If that is the case then the second call to
> skb_peek() will return a different skb then the one you passed to
> security_post_recv_datagram().
Yes. The second call to skb_peek() might return a different skb than the one
I passed to security_post_recv_datagram().
skb
On Saturday 17 November 2007 11:00:20 pm Tetsuo Handa wrote:
> Hello.
Hello.
> Paul Moore wrote:
> > Okay, well if that is the case I think you are going to have another
> > problem in that you could end up throwing away skbs that haven't been
> > through your security_post_recv_datagram() hook b
Hello.
Christoph Hellwig wrote:
> > NACK to this. Passing function parameters through the task_struct is
> > definitely not an acceptable hack
> Exactly. Having a vfsmount other than the current processes root or
> current working directory in task_struct doesn't make any sense.
The process's roo
On Fri, Nov 16, 2007 at 12:47:35PM -0500, Trond Myklebust wrote:
>
> On Sat, 2007-11-17 at 02:34 +0900, [EMAIL PROTECTED]
> wrote:
> > plain text document attachment
> > (add-wrapper-functions-for-vfs-helper-functions.patch)
> > This patch allows LSM hooks refer previously associated "struct vfsmo
13 matches
Mail list logo
