All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Haynes <tdh@excfb.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: "Victor Mataré" <dreck@vmsd.ath.cx>, linux-nfs@vger.kernel.org
Subject: Re: numeric UIDs
Date: Tue, 17 Aug 2010 12:48:32 -0500	[thread overview]
Message-ID: <4C6ACB70.7080409@excfb.com> (raw)
In-Reply-To: <20100803192241.GD31579@fieldses.org>

J. Bruce Fields wrote:
> On Tue, Aug 03, 2010 at 04:01:32AM +0200, Victor Mataré wrote:
>   
>> Hello,
>>
>> I still hope I'm mistaken in assuming I have to go back to NFSv3 if I want to 
>> skip NFSv4 UID mapping altogether and just use the numeric UIDs the way 
>> they're stored on-disk. However if that's actually true, I'd like to try and 
>> make a case for implementing an option to turn off UID mapping completely (or 
>> at least for unknown UIDs). If this is already work in progress, just ignore 
>> this mail.
>>
>> Thing is, the forced UID mapping seems to make tasks like backing up data a 
>> little inconvenient. You might want to preserve UIDs that are only known to 
>> the client.
>> But when you copy an entire root filesystem, it becomes outright destructive, 
>> because the rootfs will probably have several accounts that the server can't 
>> be expected know. Just imagine a server that's used for maintenance (like 
>> backing up and replacing hard drives) of random (foreign) systems. Idmapd will 
>> map all unknown UIDs to a single value and thereby destroy that information.
>>
>> I think I read somewhere
>>     
>
> Pointer?
>
>   

http://www.unix.com/man-page/OpenSolaris/4/nfs/

       If  a  domainname  is still not obtained following all of the preceding
       steps, nfsmapid will have no domain configured.	This  results  in  the
       following behavior:

	   o	  Outbound  "owner"  and  "owner_group"  attribute strings are
		  encoded as literal id's.  For  example,  the	UID  12345  is
		  encoded as 12345.

	   o	  nfsmapid   ignores  the  "domain"  portion  of  the  inbound
		  attribute string and performs name service lookups only  for
		  the  user  or  group.  If the user/group exists in the local
		  system name service databases, then the proper uid/gid  will
		  be mapped even when no domain has been configured.

		  This	 behavior   implies   that   the  same	administrative
		  user/group domain exists between  NFSv4  client  and	server
		  (that is, the same uid/gid's for users/groups on both client
		  and server). In the  case  of  overlapping  id  spaces,  the
		  inbound  attribute string could potentially be mapped to the
		  wrong id. However, this is not functionally  different  from
		  mapping  the	inbound string to nobody, yet provides greater
		  flexibility.





> --b.
>
>   
>> that the Sun people already have a way of handling 
>> this. Any chance Linux could do that, too?
>>
>> Please excuse me if I'm barking up the wrong tree. If this has already been 
>> discussed, I'd appreciate a pointer.
>>
>> Thanks,
>> Victor
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>     
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>   


  reply	other threads:[~2010-08-17 18:05 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-03  2:01 numeric UIDs Victor Mataré
2010-08-03 16:43 ` Jim Rees
2010-08-03 19:22   ` J. Bruce Fields
2010-08-03 21:49     ` Daniel.Muntz
2010-08-03 21:57       ` Jim Rees
2010-08-03 22:15         ` Trond Myklebust
2010-08-03 22:23           ` J. Bruce Fields
2010-08-03 22:31             ` Trond Myklebust
2010-08-03 22:42               ` J. Bruce Fields
2010-08-04  2:02                 ` Trond Myklebust
2010-08-04 17:06                   ` David Brodbeck
2010-08-04 18:30                     ` Andy Adamson
2010-08-04 21:32                       ` David Brodbeck
2010-08-11 23:06                         ` Neil Brown
2010-08-12 13:20                           ` Andy Adamson
2010-08-11 23:10                     ` Neil Brown
2010-08-05 15:34                   ` J. Bruce Fields
2010-08-11 23:22                     ` Neil Brown
2010-08-13 14:43                       ` Steve Dickson
2010-08-13 16:31                         ` J. Bruce Fields
2010-08-13 17:30                           ` Steve Dickson
     [not found]                             ` <4C658146.90207-AfCzQyP5zfLQT0dZR+AlfA@public.gmane.org>
2010-08-13 17:37                               ` J. Bruce Fields
2010-08-13 18:43                           ` Chuck Lever
2010-08-17 17:46                             ` Tom Haynes
2010-08-17 18:18                               ` J. Bruce Fields
2010-08-17 18:43                                 ` Tom Haynes
2010-08-17 18:49                                   ` J. Bruce Fields
2010-08-17 19:21                                     ` J. Bruce Fields
     [not found]                         ` <4C6559FA.5070809-AfCzQyP5zfLQT0dZR+AlfA@public.gmane.org>
2010-08-16  8:30                           ` Neil Brown
2010-08-13 14:40                 ` Steve Dickson
2010-08-03 19:22 ` J. Bruce Fields
2010-08-17 17:48   ` Tom Haynes [this message]
2010-08-17 18:24     ` J. Bruce Fields
2010-08-17 19:00       ` Tom Haynes
2010-08-17 20:08         ` David Brodbeck

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=4C6ACB70.7080409@excfb.com \
    --to=tdh@excfb.com \
    --cc=bfields@fieldses.org \
    --cc=dreck@vmsd.ath.cx \
    --cc=linux-nfs@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.