Casey Schaufler <[EMAIL PROTECTED]> wrote:
>
> Could you describe how this compares to the proposal that the
> AppArmor developers suggested recently? I expect that we can
> reduce the amount of discussion required, and maybe avoid some
> confusion if you could do that.
I don't know what that i
--- Stephen Smalley <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-08-14 at 08:53 -0700, Casey Schaufler wrote:
> > --- David Howells <[EMAIL PROTECTED]> wrote:
> >
> > > Casey Schaufler <[EMAIL PROTECTED]> wrote:
> > >
> > > > With Smack you can leave the label alone, raise CAP_MAC_OVERRIDE,
> > >
--- David Howells <[EMAIL PROTECTED]> wrote:
>
> Hi Linus, Al,
>
> Would you object greatly to functions like vfs_mkdir() gaining a security
> parameter?
Could you describe how this compares to the proposal that the
AppArmor developers suggested recently? I expect that we can
reduce the amoun
Bodo Eggert wrote:
>> Ok, do you like this slightly better? It states the subsystem, the
>> function with the error, the block nr. in the case of a too-large block,
>> and the block device on which the error occurred.
>
> - how long is BDEVNAME_SIZE? Will it fit on the stack?
#define BDEVNAME_
On Mon, 13 Aug 2007, Eric Sandeen wrote:
> Bodo Eggert wrote:
> > Warning: I'm only looking at the patch.
> >
> > You are supposed to print an error message for a user, not to write in a
> > chat window to a 1337 script kiddie. OK, you just matched the current style,
> > and your patch is IMHO OK
Hi Linus, Al,
Would you object greatly to functions like vfs_mkdir() gaining a security
parameter? What I'm thinking of is this:
int vfs_mkdir(struct inode *dir, struct dentry *dentry, int mode,
struct security *security)
Where the security context is the state of
