Trond Myklebust <[EMAIL PROTECTED]> wrote:
> > What I don't really understand is what value is gained by this exercise.
> > Are the savings sufficiently significant to justify the effort?
>
> It is not about savings, but about new functionality. Basically, the
> existence of reference-counted cre
On Tue, 2007-09-18 at 10:58 -0700, Casey Schaufler wrote:
> --- Trond Myklebust <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 2007-09-18 at 17:33 +0100, David Howells wrote:
> > > Hi Al, Christoph,
> > >
> > > Here's a new version of my credentials patch. It's still very basic, with
> > > only Ext3,
--- Trond Myklebust <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-09-18 at 17:33 +0100, David Howells wrote:
> > Hi Al, Christoph,
> >
> > Here's a new version of my credentials patch. It's still very basic, with
> > only Ext3, (V)FAT, NFS, AFS, SELinux and keyrings compiled in on an x86_64
> > arc
Trond Myklebust <[EMAIL PROTECTED]> wrote:
> What about the process' capabilities? Shouldn't they also be part of a
> credential?
Quite probably. The cred struct is not closed at this point. I certainly
would like to move some of the stuff hidden behind the security pointer in the
task struct,
On Tue, 2007-09-18 at 17:33 +0100, David Howells wrote:
> Hi Al, Christoph,
>
> Here's a new version of my credentials patch. It's still very basic, with
> only Ext3, (V)FAT, NFS, AFS, SELinux and keyrings compiled in on an x86_64
> arch kernel. The patched kernel compiles, links and runs.
>
>
David Howells <[EMAIL PROTECTED]> wrote:
> (1) Permit one process to change another process's cred struct. This means
> that a process wishing to read its own creds must use RCU read to do so,
> and a lock must be held when replacing the cred struct.
Having thought about this some mor
On 9/17/07, David Howells <[EMAIL PROTECTED]> wrote:
> A better way would be to compare fsuid/fsgid to uid/gid and to just take an
> extra ref on the incumbent cred object if they're the same, rather than always
> allocating a new one. That, I suspect, would speed up 99.99% of the cases.
Indeed.
Ulrich Drepper <[EMAIL PROTECTED]> wrote:
> In sys_faccessat you temporarily allocate a cred object which is
> discarded in the end. With a few more macro definitions you could
> create a dup_cred variant which initialized an automatic variable of
> type struct cred. This way the kmalloc/kfree p
In sys_faccessat you temporarily allocate a cred object which is
discarded in the end. With a few more macro definitions you could
create a dup_cred variant which initialized an automatic variable of
type struct cred. This way the kmalloc/kfree pair would fall away.
access is actually used frequ
On Thu, 13 Sep 2007, David Howells wrote:
>
> > Why is it trying to make it look like a variable?
>
> Like 'current' for instance?
"current" has solid *historical* reasons for being that way.
Namely: it actually *was* a variable. That worked fine for UP. It got
changed much much later.
Also
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> That "current_cred" thing is really too ugly to live.
Agreed.
> Why is it trying to make it look like a variable?
Like 'current' for instance?
static __always_inline struct task_struct *get_current(void)
{
return x86_r
On Thu, 13 Sep 2007, David Howells wrote:
>
> Here's a patch that implements a very basic set of COW credentials.
That "current_cred" thing is really too ugly to live.
Why is it trying to make it look like a variable? That will just confuse
people, and/or make them think it's a cheap thing r
12 matches
Mail list logo
