Kyle Moffett <[EMAIL PROTECTED]> wrote:
> One vaguely related question: Is there presently any way to adjust the
> per-user max-key-data limit?
There's no reason there can't be. It just needs a policy deciding. Do we
have:
(1) One control for all.
(2) One control for all non-root users; no
James Morris <[EMAIL PROTECTED]> wrote:
> > The SELinux base code will also need updating to have the security class,
> > lest
> > the following error appear in dmesg:
> >
> > context_struct_compute_av: unrecognized class 69
>
> Alternately, what's needed is a newer policy which supports u
On Jan 15, 2008, at 18:46, David Howells wrote:
(*) 01-keys-inc-payload.diff
(*) 02-keys-search-keyring.diff
(*) 03-keys-callout-blob.diff
One vaguely related question: Is there presently any way to adjust
the per-user max-key-data limit? I've been tinkering with using the
new-ish MIT k
On Tue, 15 Jan 2008, David Howells wrote:
>
> (*) 04-keys-get-label.diff
>
> A patch to allow the security label of a key to be retrieved.
> Included because of patches 05-08.
>
> (*) 05-security-current-fsugid.diff
> (*) 06-security-separate-task-bits.diff
> (*) 07-security
On Tue, 15 Jan 2008, David Howells wrote:
> The SELinux base code will also need updating to have the security class, lest
> the following error appear in dmesg:
>
> context_struct_compute_av: unrecognized class 69
Alternately, what's needed is a newer policy which supports unknown
permi
These patches add local caching for network filesystems such as NFS.
The patches can roughly be broken down into a number of sets:
(*) 01-keys-inc-payload.diff
(*) 02-keys-search-keyring.diff
(*) 03-keys-callout-blob.diff
Three patches to the keyring code made to help the CIFS peop