From: Jesse Pollard <jesse@cats-chateau.net>
To: =?CP 1252?q?S=F8ren=20Hansen?= <sh@warma.dk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: UID/GID mapping system
Date: Mon, 15 Mar 2004 11:05:36 -0600 [thread overview]
Message-ID: <04031511053600.13518@tabby> (raw)
In-Reply-To: <1079103602.1571.26.camel@quaoar>
On Friday 12 March 2004 09:00, Søren Hansen wrote:
> fre, 2004-03-12 kl. 14:52 skrev Jesse Pollard:
> > > Let's just for a second assume that I'm the slow one here. Why is the
> > > world a less secure place after this system is incorporated into the
> > > kernel?
> >
> > Because a rogue client will have access to every uid on the server.
>
> As opposed to now when a rogue client is very well contained?
>
> > Mapping provides a shield to protect the server.
>
> A mapping system could provide extra security if implemented on the
> server. That's true. This is, however, not what I'm trying to do. This
> system is NOT a security related one (it doesn't increase nor decrease
> security), but rather a convenience related one.
Then it becomes an identity mapping (as in 1:1) and is therefore
not usefull.
If you are doing double mapping, then I (as a server administrator)
would not export the filesystem to you.
The current situation is always a 1:1 mapping (NFS version < 4). Therefore
any filesystem export is by definition within the same security domain.
If you as an administrator of a client host violate the UIDs assigned to
you (by hiding the audit trail), then you are violating the rules established
in that security domain; and should not be trusted - and the client host
should not have an available export.
It is never necessary to map on a client. It means that the server has been
improperly setup, or that the client is not within the proper security domain.
next prev parent reply other threads:[~2004-03-15 17:06 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-08 19:45 UID/GID mapping system Søren Hansen
2004-03-09 16:46 ` Jesse Pollard
2004-03-09 19:28 ` Søren Hansen
2004-03-10 15:28 ` Jesse Pollard
2004-03-10 17:58 ` Søren Hansen
2004-03-10 21:41 ` Jesse Pollard
2004-03-10 22:45 ` Trond Myklebust
2004-03-11 8:29 ` Søren Hansen
2004-03-11 14:31 ` Jesse Pollard
2004-03-11 14:45 ` Søren Hansen
2004-03-11 15:58 ` J. Bruce Fields
2004-03-11 19:41 ` Trond Myklebust
2004-03-12 8:41 ` Søren Hansen
2004-03-11 14:10 ` Jesse Pollard
2004-03-10 23:46 ` Andreas Dilger
2004-03-11 14:08 ` Jesse Pollard
2004-03-11 16:02 ` J. Bruce Fields
2004-03-12 13:58 ` Jesse Pollard
2004-03-12 20:08 ` J. Bruce Fields
2004-03-15 17:17 ` Jesse Pollard
2004-03-15 17:49 ` Andreas Dilger
[not found] ` <fa.ct61k6d.bm43gj@ifi.uio.no>
2004-03-11 19:40 ` Kevin Buhr
2004-03-11 23:10 ` Jamie Lokier
2004-03-12 14:49 ` Pavel Machek
2004-03-11 8:22 ` Søren Hansen
2004-03-11 14:18 ` Jesse Pollard
2004-03-11 14:39 ` Søren Hansen
2004-03-12 13:52 ` Jesse Pollard
2004-03-12 15:00 ` Søren Hansen
2004-03-15 17:05 ` Jesse Pollard [this message]
2004-03-16 8:08 ` Søren Hansen
2004-03-09 19:28 ` Søren Hansen
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=04031511053600.13518@tabby \
--to=jesse@cats-chateau.net \
--cc=linux-kernel@vger.kernel.org \
--cc=sh@warma.dk \
/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