From: Jan Harkes <jaharkes@cs.cmu.edu>
To: David Howells <dhowells@redhat.com>
Cc: torvalds@transmeta.com, mingo@redhat.com, arjanv@redhat.com,
alan@redhat.com, viro@math.psu.edu, linux-kernel@vger.kernel.org
Subject: Re: Linux authentication / credential management
Date: Wed, 9 Apr 2003 15:39:03 -0400 [thread overview]
Message-ID: <20030409193903.GA31944@delft.aura.cs.cmu.edu> (raw)
In-Reply-To: <3946.1049901134@warthog.warthog>
On Wed, Apr 09, 2003 at 04:12:14PM +0100, David Howells wrote:
> The first part of what I'm thinking of is a structure like the
> following that has a Process Authentication Group ID and a list of
> authentication tokens for filesystems such as AFS & NFSv4 kerberos
> keys, NTFS ACLs, SAMBA login details.
PAGs have been proposed over and over again and there is one fundamental
problem, my PAG isn't your PAG.
(although in this specific case, if you're looking at it with the AFS
hat it probably is).
Some people want to have an authentication identifier they can keep
synchronized across a cluster, so they want to be able to set the 'PAG'
to any arbitrary value. However Coda (and AFS) prefer to have something
that just guarantees to be a unique identifier for a group of related
tasks (aka. newpag). Allowing someone to set the pag in this case
nullifies the usefulness of the tag because there is no guarantee that
it is unique. It would be similar to allowing someone to specify their
own process id.
What happened to your 'task ornaments', I figured that that would have
been the best way to tag processes with information and allow individual
filesystems to define their own preferred semantics.
http://www.ussg.iu.edu/hypermail/linux/kernel/0201.3/0480.html
Jan
prev parent reply other threads:[~2003-04-09 19:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-09 15:12 David Howells
2003-04-09 18:58 ` Chris Wright
2003-04-09 19:39 ` Jan Harkes [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030409193903.GA31944@delft.aura.cs.cmu.edu \
--to=jaharkes@cs.cmu.edu \
--cc=alan@redhat.com \
--cc=arjanv@redhat.com \
--cc=dhowells@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=torvalds@transmeta.com \
--cc=viro@math.psu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®