Stephen points out listsecurity results should simply be separated by
the \0 which modules already append. New patch appended.
Thanks, Stephen.
-serge
Signed-off-by: Serge Hallyn <[EMAIL PROTECTED]>
--
stacker.c | 78 +++---
1 files
Quoting Stephen Smalley ([EMAIL PROTECTED]):
> These hooks pose a similar problem for stacking as with the
> [gs]etprocattr hooks, although [gs]etsecurity have the benefit of
> already taking a distinguishing name suffix (the part after the
> security. prefix). Note also that inode_getsecurity
Quoting Stephen Smalley ([EMAIL PROTECTED]):
These hooks pose a similar problem for stacking as with the
[gs]etprocattr hooks, although [gs]etsecurity have the benefit of
already taking a distinguishing name suffix (the part after the
security. prefix). Note also that inode_getsecurity
Stephen points out listsecurity results should simply be separated by
the \0 which modules already append. New patch appended.
Thanks, Stephen.
-serge
Signed-off-by: Serge Hallyn [EMAIL PROTECTED]
--
stacker.c | 78 +++---
1 files
On Mon, 2005-07-11 at 12:51 -0500, [EMAIL PROTECTED] wrote:
> I can imagine a few ways of fixing this:
>
> 1. We simply expect that only one module use xattrs. This
> is probably unacceptable, as we will want both EVM and selinux
> to store xattrs.
Note that these
Thanks Stephen.
More comments below. This finally proves that I need to provide some
documentation for each hook under stacker showing how modules are
expected to interact. This hopefully will help me catch things like
this. Hopefully it would also be useful to module writers in general.
On Thu, 2005-06-30 at 14:50 -0500, [EMAIL PROTECTED] wrote:
> Adds the actual stacker LSM.
> +static int stacker_inode_getsecurity(struct inode *inode, const char *name,
> void *buffer, size_t size)
> +{
> +
>
On Thu, 2005-06-30 at 14:50 -0500, [EMAIL PROTECTED] wrote:
Adds the actual stacker LSM.
snip
+static int stacker_inode_getsecurity(struct inode *inode, const char *name,
void *buffer, size_t size)
+{
+
Thanks Stephen.
More comments below. This finally proves that I need to provide some
documentation for each hook under stacker showing how modules are
expected to interact. This hopefully will help me catch things like
this. Hopefully it would also be useful to module writers in general.
On Mon, 2005-07-11 at 12:51 -0500, [EMAIL PROTECTED] wrote:
I can imagine a few ways of fixing this:
1. We simply expect that only one module use xattrs. This
is probably unacceptable, as we will want both EVM and selinux
to store xattrs.
Note that these particular
Quoting Tony Jones ([EMAIL PROTECTED]):
> Hey Serge,
> Seemed useful to be able to view which modules had been unloaded.
> Easier to maintain them on their own list than to compute the difference
> of and . Patch attached, not sure if you
> are cool with reusing the 'unload' file.
Attached is a
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
> Quoting Tony Jones ([EMAIL PROTECTED]):
> Attached is a patch to re-introduce the necessary locking to allow
> unloading of LSMs. I don't have any performance results nor hardcore
> stability tests yet.
And here is a patch on top of that to use
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
Quoting Tony Jones ([EMAIL PROTECTED]):
Attached is a patch to re-introduce the necessary locking to allow
unloading of LSMs. I don't have any performance results nor hardcore
stability tests yet.
And here is a patch on top of that to use
Quoting Tony Jones ([EMAIL PROTECTED]):
Hey Serge,
Seemed useful to be able to view which modules had been unloaded.
Easier to maintain them on their own list than to compute the difference
of stacked_modules and all_modules. Patch attached, not sure if you
are cool with reusing the 'unload'
Quoting Tony Jones ([EMAIL PROTECTED]):
> I'm going to have to give it some thought, but a new rmmod hook does seem
> a good solution off the top of my head.
In reponse to some prodding by Tony, here is a summary of the current
locking scheme in stacker, sprinkled with some notes about one way
Quoting Tony Jones ([EMAIL PROTECTED]):
I'm going to have to give it some thought, but a new rmmod hook does seem
a good solution off the top of my head.
In reponse to some prodding by Tony, here is a summary of the current
locking scheme in stacker, sprinkled with some notes about one way lsm
On Mon, Jul 04, 2005 at 03:06:46PM -0500, [EMAIL PROTECTED] wrote:
> > You are calling __symbol_get("ops").
> >
> > Maybe (/probably :-)) I'm totally misunderstanding what you are doing but:
> > a) I would have thought you would need to call symbol_get on the name the
> >caller was passing,
Quoting Tony Jones ([EMAIL PROTECTED]):
> On Mon, Jul 04, 2005 at 06:51:35AM -0500, [EMAIL PROTECTED] wrote:
>
> > > I don't think your symbol_get() is doing what you think it is ;-)
>
> > Hmm, I wonder whether something changed. It shouldn't be possible to
> > rmmod module b if module a has
On Mon, Jul 04, 2005 at 06:51:35AM -0500, [EMAIL PROTECTED] wrote:
> > I don't think your symbol_get() is doing what you think it is ;-)
> Hmm, I wonder whether something changed. It shouldn't be possible to
> rmmod module b if module a has done a symbol_get on it...
Are you thinking of
Quoting Tony Jones ([EMAIL PROTECTED]):
> Hey Serge,
>
> I don't think your symbol_get() is doing what you think it is ;-)
Hmm, I wonder whether something changed. It shouldn't be possible to
rmmod module b if module a has done a symbol_get on it... This may mean
more stringent locking will be
Quoting Tony Jones ([EMAIL PROTECTED]):
Hey Serge,
I don't think your symbol_get() is doing what you think it is ;-)
Hmm, I wonder whether something changed. It shouldn't be possible to
rmmod module b if module a has done a symbol_get on it... This may mean
more stringent locking will be
On Mon, Jul 04, 2005 at 06:51:35AM -0500, [EMAIL PROTECTED] wrote:
I don't think your symbol_get() is doing what you think it is ;-)
Hmm, I wonder whether something changed. It shouldn't be possible to
rmmod module b if module a has done a symbol_get on it...
Are you thinking of
Quoting Tony Jones ([EMAIL PROTECTED]):
On Mon, Jul 04, 2005 at 06:51:35AM -0500, [EMAIL PROTECTED] wrote:
I don't think your symbol_get() is doing what you think it is ;-)
Hmm, I wonder whether something changed. It shouldn't be possible to
rmmod module b if module a has done a
On Mon, Jul 04, 2005 at 03:06:46PM -0500, [EMAIL PROTECTED] wrote:
You are calling __symbol_get(ops).
Maybe (/probably :-)) I'm totally misunderstanding what you are doing but:
a) I would have thought you would need to call symbol_get on the name the
caller was passing, i.e
24 matches
Mail list logo
