public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jesse Pollard <jesse@cats-chateau.net>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Andreas Dilger <adilger@cluster fs.com> =?CP
	1252?q?=2CS=F8ren=20Hansen?= <sh@warma.dk>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: UID/GID mapping system
Date: Mon, 15 Mar 2004 11:17:43 -0600	[thread overview]
Message-ID: <04031511174301.13518@tabby> (raw)
In-Reply-To: <20040312200833.GC24074@fieldses.org>

On Friday 12 March 2004 14:08, J. Bruce Fields wrote:
> On Fri, Mar 12, 2004 at 07:58:33AM -0600, Jesse Pollard wrote:
> > Not really - it would be a 1:1 map... so what would be the purpose?
>
> Are you asking what would be the purpose of client-side mapping?
>
> So, in the worst case you have a laptop that you want to be able to
> simultaneously mount one NFS server maintained by organization X, and
> another maintained by organization Y.  But unfortunately you have
> different uid's in X and Y.  (Given sufficiently large independent
> organizations X and Y this is inevitable and unfixable.)  What do you
> do?

The server maps the valid uid to the uid used on the client.

Obviously the client is not under the control of the server security domain.

> > The problem is in the audit - the server would report a violation in
> > uid xxx. Which according to it's records is not used on the penetrated
> > client (at least not via the filesystem). Yet the administrator would
> > report that the uid is valid (because of a bogus local map).
>
> I don't understand your description of the problem; could you be more
> specific?  E.g., what do you mean by "a violation in uid xxx"?
>
> In general if your server trusts clients to get uid's right, and if
> users already have sufficient control over the client to tell the kernel
> to remap uid's, then they can already lie to the server about their uid.
> (It probably happens every now and then already just by mistake; e.g. if
> people are throwing a linux distribution on their personal laptop and
> expecting to be able to mount the nfsd server there's a good chance
> they'll forget to give themselves the right uid from the start.)

1. your first assumpion: "if your server trusts clients". The server
	should NOT trust a remote client.

2. "then they can already lie to the server about their uid" means the client
	is NOT under control and again should not be trusted.

  reply	other threads:[~2004-03-15 17:18 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 [this message]
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
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=04031511174301.13518@tabby \
    --to=jesse@cats-chateau.net \
    --cc=adilger@cluster \
    --cc=bfields@fieldses.org \
    /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