Actions
Bug #897
openNFS server should not show ephemeral IDs
Status:
New
Priority:
Normal
Assignee:
-
Category:
nfs - NFS server and client
Start date:
2011-04-11
Due date:
% Done:
0%
Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:
External Bug:
Description
We have this issue too. (I've seen it).
http://mail.opensolaris.org/pipermail/cifs-discuss/2011-April/003449.html
I wasn't sure if NFS was supposed to show ephemeral IDs
to clients, but apparently it's not supposed to.
Updated by Marcel Telka about 9 years ago
- Difficulty set to Medium
- Tags set to needs-triage
Gordon, what exactly is the problem here? Unfortunately, the URL linked in the Description no longer works.
Thank you.
Updated by Marcel Telka about 7 years ago
From emails:
Date: Mon, 14 Apr 2014 11:43:38 -0400 From: Gordon Ross To: Marcel Telka IIRC, The problem was that we "leak" ephemeral ID information to other systems, where it may be stored, and then at some later date we may choose a different ephemeral ID, and the other systems get confused... My understanding of the idmap design was that the NFS server should try not to expose ephemeral IDs to remote systems, instead presenting one of the special NFS IDs (unknown, or whatever) Gordon
Date: Tue, 15 Apr 2014 09:36:04 +0200 From: Marcel Telka To: Gordon Ross Hi Gordon, Do you have some example how exactly we leak the ID? Do you mean something like "ls -l" at the NFS client when the client might see the ephemeral ID as uid or gid? Thank you.
Date: Tue, 15 Apr 2014 12:40:23 -0400 From: Gordon Ross To: Marcel Telka Yes, exactly. Seeing the ephemeral ID at the client is (potentially) a problem.
Date: Tue, 15 Apr 2014 19:03:21 +0200 From: Marcel Telka To: Gordon Ross Isn't similar problem to see the ephemeral IDs locally (without NFS involved)? # touch file # /usr/bin/chown -s S-1-5-11 file # idmap dump gsid:S-1-5-9 == gid:2147483650 gsid:S-1-5-11 == uid:2147483649 # /bin/ls -l file -rw-r--r-- 1 2147483649 root 0 apr 8 22:43 file #
Actions