On Thursday 06 December 2007 06:40, David Howells wrote:
> Add a function - cancel_rejected_write() - to excise a rejected write from
> the pagecache. This function is related to the truncation family of
> routines. It permits the pages modified by a network filesystem client
> (such as AFS) to b
On Thursday 06 December 2007 06:39, David Howells wrote:
> Recruit a couple of page flags to aid in cache management. The following
> extra flags are defined:
>
> (1) PG_fscache (PG_owner_priv_2)
>
> The marked page is backed by a local cache and is pinning resources in
> the cache driver.
>
On Thursday 06 December 2007 06:39, David Howells wrote:
> The attached patch causes read_cache_pages() to release page-private data
> on a page for which add_to_page_cache() fails or the filler function fails.
> This permits pages with caching references associated with them to be
> cleaned up.
>
Stephen Smalley <[EMAIL PROTECTED]> wrote:
> Do any of the interfaces allow a task to act on a cache other than one
> it has created?
No.
> How does the task identify the desired cache?
Each file descriptor opened creates one separate cache instance. Any commands
sent over that filedescriptor
On Thu, 2007-12-13 at 17:01 +, David Howells wrote:
> Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > They would correspond with the operations provided by the /dev/cachefiles
> > interface, at the granularity you want to support distinctions to be made.
>
> Can this be made simpler by the f
Stephen Smalley <[EMAIL PROTECTED]> wrote:
> They would correspond with the operations provided by the /dev/cachefiles
> interface, at the granularity you want to support distinctions to be made.
Can this be made simpler by the fact that /dev/cachefiles has its own unique
label (cachefiles_dev_t)
On Thu, 2007-12-13 at 15:36 +, David Howells wrote:
> Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > It is just a way of carving up the permission space, typically based on
> > object type, but it can essentially be arbitrary. The check in this
> > case seems specific to cachefiles since it
Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> Yes, we could easily make a simple program that just invokes a
> libselinux function that in turn grabs the proper context from some
> context configuration file under /etc/selinux/$SELINUXTYPE/contexts/ and
> outputs it. Dan can help with that.
Th
On Wed, 2007-12-12 at 22:55 +, David Howells wrote:
> Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > More likely, run it at build time in your .spec file to generate
> > cachefiles.conf,
>
> I don't think sticking it in cachefiles.conf is a good idea necessarily.
> That has to be an adminis
Stephen Smalley <[EMAIL PROTECTED]> wrote:
> It is just a way of carving up the permission space, typically based on
> object type, but it can essentially be arbitrary. The check in this
> case seems specific to cachefiles since it is controlling an operation
> on the /dev/cachefiles interface th
On Wed, 2007-12-12 at 22:49 +, David Howells wrote:
> Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > > Have you example code for the security hook you mention? I'm not sure I
> > > understand why security_secctx_to_secid() is not sufficient.
> >
> > security_secctx_to_secid() would just va
Quoting KaiGai Kohei ([EMAIL PROTECTED]):
> [EMAIL PROTECTED] wrote:
>> Quoting Andrew Morgan ([EMAIL PROTECTED]):
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> Serge E. Hallyn wrote:
I defined CAP_NS_UNSHARE as bit 32 as an experiment, and had to do some
finagling/combina
12 matches
Mail list logo
