-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
>> Does that explain it?
>
> Yes, thanks, but then it still could come in handy to have fE be a full
> bitset, so the application gets some eff caps automatically, while
> others it has to manually set...
[We touched on this a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This contains a typo:
Serge E. Hallyn wrote:
>>From 588755d9498c87c4e963527ba0f49c11107de354 Mon Sep 17 00:00:00 2001
> From: Serge E. Hallyn <[EMAIL PROTECTED]>
> Date: Wed, 27 Jun 2007 19:55:27 -0400
> Subject: [PATCH 1/1] file capabilities: get_fil
Any chance you can remove linux-fsdevel from the CC list? I don't think this
has anything to do with filesystems.
Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.
-
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the bo
Quoting James Morris ([EMAIL PROTECTED]):
> On Wed, 27 Jun 2007, Serge E. Hallyn wrote:
>
> > Patch tests fine for me for expected capability behavior with lsm=n,
> > lsm=y, lsm=y+capability=y, lsm=y+selinux=y, and lsm=y+caps=y+selinux=y.
> >
> > So while I'm opposed to the patch, it appears to b
Serge E. Hallyn wrote:
Here's the first patch (of several or many to come) to address some of
Andrew's comments.
Kaigai, IIUC cap_names.h will eventually be automatically updated? (I
had to manually tweak it for testing as the new kernel sources were not
located on the test system)
The origin
From: Casey Schaufler <[EMAIL PROTECTED]>
Date: Wed, 27 Jun 2007 17:27:17 -0700 (PDT)
> --- David Miller <[EMAIL PROTECTED]> wrote:
>
> > Neither of those are reasons why something should go into the tree.
>
> They reflect the corporate reality of the open source community.
> If you're going to
--- David Miller <[EMAIL PROTECTED]> wrote:
> From: Crispin Cowan <[EMAIL PROTECTED]>
> Date: Wed, 27 Jun 2007 15:46:57 -0700
>
> > But we do not want to prevent other people from using SELinux if it
> > suits them. Linux is about choice, and that is especially vital in
> > security. As Linus hi
>From 588755d9498c87c4e963527ba0f49c11107de354 Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn <[EMAIL PROTECTED]>
Date: Wed, 27 Jun 2007 19:55:27 -0400
Subject: [PATCH 1/1] file capabilities: get_file_caps cleanups
Two cleanups relating to set_file caps.
Rename set_file_caps to get_file_caps, sin
From: Crispin Cowan <[EMAIL PROTECTED]>
Date: Wed, 27 Jun 2007 15:46:57 -0700
> But we do not want to prevent other people from using SELinux if it
> suits them. Linux is about choice, and that is especially vital in
> security. As Linus himself observed when LSM was started, there are a
> lot of
Sean wrote:
> On Wed, 27 Jun 2007 14:06:04 -0700
> Crispin Cowan <[EMAIL PROTECTED]> wrote:
>
>> I am hoping for a reconciliation where the people who don't like
>> AppArmor live with it by not using it. AppArmor is not intended to
>> replace SELinux, it is intended to address a different set of
On Wed, 27 Jun 2007 14:06:04 -0700
Crispin Cowan <[EMAIL PROTECTED]> wrote:
> I am hoping for a reconciliation where the people who don't like
> AppArmor live with it by not using it. AppArmor is not intended to
> replace SELinux, it is intended to address a different set of goals.
You keep sayin
Adrian Bunk wrote:
> On Tue, Jun 26, 2007 at 07:47:00PM -0700, Andrew Morton wrote:
>
>> Do you agree with the "irreconcilable" part? I think I do.
I am hoping for a reconciliation where the people who don't like
AppArmor live with it by not using it. AppArmor is not intended to
replace SELinu
On Wednesday 27 June 2007 01:46, Trond Myklebust wrote:
> On Tue, 2007-06-26 at 16:15 -0700, [EMAIL PROTECTED] wrote:
> > To remove conditionally passing of vfsmounts to the LSM, a nameidata
> > struct can be instantiated in the nfsd and mqueue filesystems. This
> > however results in useless info
On Wed, 27 Jun 2007, Serge E. Hallyn wrote:
> Patch tests fine for me for expected capability behavior with lsm=n,
> lsm=y, lsm=y+capability=y, lsm=y+selinux=y, and lsm=y+caps=y+selinux=y.
>
> So while I'm opposed to the patch, it appears to be safe.
I've also tested a bunch of scenarios: allmod
Quoting Serge E. Hallyn ([EMAIL PROTECTED]):
> Quoting James Morris ([EMAIL PROTECTED]):
> > On Wed, 27 Jun 2007, Serge E. Hallyn wrote:
> >
> > > Quoting Kyle Moffett ([EMAIL PROTECTED]):
> > > > This whole discussion boils down to 2 points:
> > >
> > > Yes it can, but not the two you list.
> >
Quoting James Morris ([EMAIL PROTECTED]):
> On Wed, 27 Jun 2007, Serge E. Hallyn wrote:
>
> > Quoting Kyle Moffett ([EMAIL PROTECTED]):
> > > This whole discussion boils down to 2 points:
> >
> > Yes it can, but not the two you list.
> >
> > > 1) As currently implemented, no LSM may be safely
Here's the first patch (of several or many to come) to address some of
Andrew's comments.
Kaigai, IIUC cap_names.h will eventually be automatically updated? (I
had to manually tweak it for testing as the new kernel sources were not
located on the test system)
thanks,
-serge
>From fefcd341e478bd
On Tue, Jun 26, 2007 at 07:47:00PM -0700, Andrew Morton wrote:
> On Tue, 26 Jun 2007 19:24:03 -0700 John Johansen <[EMAIL PROTECTED]> wrote:
>
> > >
> > > so... where do we stand with this? Fundamental, irreconcilable
> > > differences over the use of pathname-based security?
> > >
> > There c
On Wed, 27 Jun 2007, Serge E. Hallyn wrote:
> Quoting Kyle Moffett ([EMAIL PROTECTED]):
> > This whole discussion boils down to 2 points:
>
> Yes it can, but not the two you list.
>
> > 1) As currently implemented, no LSM may be safely rmmod-ed
>
> That's not the rationale for the patch, it's
Quoting Kyle Moffett ([EMAIL PROTECTED]):
> This whole discussion boils down to 2 points:
Yes it can, but not the two you list.
> 1) As currently implemented, no LSM may be safely rmmod-ed
That's not the rationale for the patch, it's just some talking point you
picked up. The rationale for th
On Wednesday 27 June 2007 12:58, Kyle Moffett wrote:
> I seem to recall you could actually end up racing and building a path
> to the file in those directories as "a/d/0/3" or some other path at
> which it never even remotely existed. I'd love to be wrong,
Cheer up, you recall wrong.
> but I can'
Quoting Andrew Morgan ([EMAIL PROTECTED]):
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Serge E. Hallyn wrote:
> >
> >> I don't particularly mind, but can you point out any case where
> >> it is an advantage to have the one bit for f'E rather than just
> >> drop f'E altogether? Instead
* Hawk Xu ([EMAIL PROTECTED]) wrote:
> Add hook inode_post_removexattr for updating inode security field after
> successful removexattr operation.
That is an insufficient explanation of why it's needed, who is using it,
etc.
thanks,
-chris
-
To unsubscribe from this list: send the line "unsubscr
Add hook inode_post_removexattr for updating inode security field after
successful removexattr operation.
Signed-off-by: Hawk Xu <[EMAIL PROTECTED]>
---
fs/xattr.c |7 +--
include/linux/security.h | 19 +++
security/dummy.c |6 ++
3 file
On Jun 26, 2007, at 22:24:03, John Johansen wrote:
other issues that have been raised are:
- the use of d_path to generate the pathname used for mediation when a
file is opened.
- Generating the pathname using a reverse walk is considered ugly
A little more than "ugly". In this basic concu
25 matches
Mail list logo
