From: David Howells <dhowells@warthog.cambridge.redhat.com>
To: Jan Harkes <jaharkes@cs.cmu.edu>,
Linus Torvalds <torvalds@transmeta.com>,
David Howells <dhowells@redhat.com>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
openafs-devel@openafs.org
Subject: Re: [PATCH] in-core AFS multiplexor and PAG support
Date: Tue, 13 May 2003 19:21:05 +0100 [thread overview]
Message-ID: <9558.1052850065@warthog.warthog> (raw)
In-Reply-To: <20030513172029.GB25295@delft.aura.cs.cmu.edu>
> Right, if some process/user opens a file and then passes the descriptor
> to another process/user which closes it. The close should operate under
> the same permissions as the original opener.
As long as the token isn't explicitly withdrawn. With my token structure, I've
defined it such that if the list_head in the token struct is ever empty, then
the token is withdrawn.
Furthermore, I'm considering it such that the the filesystem will select a
token from the PAG's token ring in the file_operations->open method and will
attach it to the file->f_token at that point for quick reference later.
> If someone obtains my user id on in any way (i.e. weak password/
> bufferoverflow/ root exploit), he should not be allowed to use or access
> my tokens as he hasn't proven his identity. In this case he would either
> still be in his original process authentication group, or a new and
> empty PAG. But definitely not in any of my authentication groups.
>
> Which is also why joining a PAG should never be allowed.
Someone asked for it, but I suspect if allowed at all it may be best that this
ability is governed by its own capability bit and also that the security
interface should be consulted.
David
next prev parent reply other threads:[~2003-05-13 18:21 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-13 15:39 [PATCH] in-core AFS multiplexor and PAG support David Howells
2003-05-13 15:52 ` Linus Torvalds
2003-05-13 15:44 ` Alan Cox
2003-05-13 16:52 ` Jan Harkes
2003-05-13 16:57 ` Linus Torvalds
2003-05-13 16:39 ` Alan Cox
2003-05-13 21:46 ` Russ Allbery
2003-05-16 15:38 ` [OpenAFS-devel] " Derek Atkins
2003-05-13 16:05 ` David Howells
2003-05-13 16:24 ` Douglas E. Engert
2003-05-13 16:47 ` Linus Torvalds
2003-05-13 17:20 ` Jan Harkes
2003-05-13 18:21 ` David Howells [this message]
2003-05-13 18:51 ` Douglas E. Engert
2003-05-13 20:33 ` [OpenAFS-devel] " Jan Harkes
2003-05-13 21:26 ` Douglas E. Engert
2003-05-13 21:40 ` [OpenAFS-devel] " Jan Harkes
2003-05-13 22:14 ` Douglas E. Engert
2003-05-14 2:02 ` Jan Harkes
2003-05-17 12:30 ` Pavel Machek
2003-05-18 14:22 ` Nathan Neulinger
2003-05-18 18:06 ` [OpenAFS-devel] " Pavel Machek
2003-05-13 17:23 ` Trond Myklebust
2003-05-15 11:41 ` Ingo Oeser
2003-05-13 17:42 ` David Howells
2003-05-13 16:03 ` Christoph Hellwig
2003-05-13 16:12 ` David Howells
2003-05-13 20:23 ` Christoph Hellwig
2003-05-13 16:39 ` Jeff Garzik
2003-05-13 16:57 ` David Howells
[not found] <20030513182950.GB30766@delft.aura.cs.cmu.edu>
2003-05-13 18:53 ` David Howells
-- strict thread matches above, loose matches on Subject: below --
2003-05-13 15:34 David Howells
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=9558.1052850065@warthog.warthog \
--to=dhowells@warthog.cambridge.redhat.com \
--cc=dhowells@redhat.com \
--cc=jaharkes@cs.cmu.edu \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=openafs-devel@openafs.org \
--cc=torvalds@transmeta.com \
/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