--- Joshua Brindle <[EMAIL PROTECTED]> wrote:
> Casey Schaufler wrote:
> >>> +static int smack_shm_associate(struct shmid_kernel *shp, int shmflg)
> >>> +{
> >>> + smack_t *ssp = smack_of_shm(shp);
> >>> + int rc;
> >>> +
> >>> + if (ssp == NULL)
> >>> + return 0;
> >>> +
> >>> + rc = smk_curacc(ssp, MAY_READWRITE);
> >>> + return rc;
> >>> +}
> >>>
> >> No read-only or write-only shm mappings?
> >>
> >
> > Still thinking about it.
> >
> >
>
> I think if you actually want to use this in a guard like policy you are
> going to need it (for at least shm and msgq).
Fair enough. Ok, I'm convinced. On the work queue it goes.
> BTW, you never responded
> to my last email about the granularity required to make a high
> throughput front channel and a low bandwidth backchannel for guards.
That's true. I'd like to wait until I have an answer that makes sense,
and as you've been following the thread you know that I have lots of
things to work out. I haven't forgotten you.
Casey Schaufler
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
