Casey Schaufler <[EMAIL PROTECTED]> wrote:
> Grumble. Yet another thing to undo in the near future. I still
> hope to suggest what I would consider a viable alternative "soon".
Use a struct key with the overrides attached? The key can be generated by
SELinux or whatever module is there.
David
-
--- James Morris <[EMAIL PROTECTED]> wrote:
> On Thu, 9 Aug 2007, David Howells wrote:
>
> > James Morris <[EMAIL PROTECTED]> wrote:
> >
> > > David, I've looked at the code and can't see that you need to access the
> > > label itself outside the LSM. Could you instead simply pass the inode
On Thu, 9 Aug 2007, David Howells wrote:
> James Morris <[EMAIL PROTECTED]> wrote:
>
> > David, I've looked at the code and can't see that you need to access the
> > label itself outside the LSM. Could you instead simply pass the inode
> > pointer around?
>
> It's not quite that simple. I ne
James Morris <[EMAIL PROTECTED]> wrote:
> David, I've looked at the code and can't see that you need to access the
> label itself outside the LSM. Could you instead simply pass the inode
> pointer around?
It's not quite that simple. I need to impose *two* security labels in
cachefiles_begin_s
On Thu, 9 Aug 2007, Casey Schaufler wrote:
> This is SELinux specific functionality. It should not be an LSM
> interface.
As long as the security labels are themselves not being exported to the
kernel to be used e.g. for display or transport, then I agree, and we
should avoid passing them arou
On Thu, 9 Aug 2007, David Howells wrote:
> James Morris <[EMAIL PROTECTED]> wrote:
>
> > > + u32 (*inode_get_secid)(struct inode *inode);
> >
> > To maintain API consistency, please return an int which only acts as an
> > error code, and returning the secid via a *u32 function parameter.
>
> D
James Morris <[EMAIL PROTECTED]> wrote:
> > + u32 (*inode_get_secid)(struct inode *inode);
>
> To maintain API consistency, please return an int which only acts as an
> error code, and returning the secid via a *u32 function parameter.
Does that apply to *all* the functions, irrespective of w
On Thu, 9 Aug 2007, David Howells wrote:
> + u32 (*inode_get_secid)(struct inode *inode);
To maintain API consistency, please return an int which only acts as an
error code, and returning the secid via a *u32 function parameter.
- James
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe
Casey Schaufler <[EMAIL PROTECTED]> wrote:
> This is SELinux specific functionality. It should not be an LSM
> interface.
This is what I worked out in conjunction with the denizens of the SELinux
mailing list. What would you have me do differently? Change things like:
u32 (*act_as_sec
--- Stephen Smalley <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-08-09 at 10:07 -0700, Casey Schaufler wrote:
> > --- David Howells <[EMAIL PROTECTED]> wrote:
> >
> > > Permit an inode's security ID to be obtained by the CacheFiles module.
> This
> > > is
> > > then used as the SID with which file
On Thu, 2007-08-09 at 10:07 -0700, Casey Schaufler wrote:
> --- David Howells <[EMAIL PROTECTED]> wrote:
>
> > Permit an inode's security ID to be obtained by the CacheFiles module. This
> > is
> > then used as the SID with which files and directories will be created in the
> > cache.
>
> This i
--- David Howells <[EMAIL PROTECTED]> wrote:
> Permit an inode's security ID to be obtained by the CacheFiles module. This
> is
> then used as the SID with which files and directories will be created in the
> cache.
This is SELinux specific functionality. It should not be an LSM
interface.
Ca
Permit an inode's security ID to be obtained by the CacheFiles module. This is
then used as the SID with which files and directories will be created in the
cache.
Signed-Off-By: David Howells <[EMAIL PROTECTED]>
---
include/linux/security.h | 13 +
security/dummy.c |6
Permit an inode's security ID to be obtained by the CacheFiles module. This is
then used as the SID with which files and directories will be created in the
cache.
Signed-Off-By: David Howells <[EMAIL PROTECTED]>
---
include/linux/security.h | 13 +
security/dummy.c |6
14 matches
Mail list logo
