On Mon, Oct 08, 2012 at 05:03:04PM +1100, NeilBrown wrote: > On Thu, 4 Oct 2012 12:07:39 -0400 "J. Bruce Fields" <bfields@xxxxxxxxxxxx> > wrote: > > It's not the nfsd behavior that bothers me--there's nothing we can do > > about the fact that access by filehandle can bypass directory > > permissions. > > > > What bothers is that mountd will apparently allow anyone to do a lookup > > anywhere in an exported filesystem. > > Not anyone - it requires a privileged source port from a known host. > So it is only "anyone who can get 'root'". As you know, that's not necessarily a good asumption. And if somebody's using sec=krb5, they're explicitly saying that they don't trust that assumption. > > Getting all the id->name mappings for a 100-entry directory is going to > > require a 100 serialized upcalls to idmapd (and then possibly ldap), and > > by default it looks like the idmapd cache will go cold after 10 > > minutes.... Not hard to imagine that could be a problem. > > > > Running multiple idmapd process would be easy and might help? Though > > not if the client's just giving us the getattrs one at a time. > > > > Or maybe the problem's somewhere else entirely, but that's a real bug if > > we aren't giving good performance on /home. > > I did some experimenting.. > On both 'client' and 'server': > for i in `seq 2000 3000`; do echo u$i:x:$i:1000::/nohome:/bin/false; done > >> /etc/passwd > > On server in suitable directory > > for i in `seq 2000 3000`; do mkdir $i ; chown u$i $i ; done > > Mount that directory onto the client with NFSv3 and "time ls -l" takes a > little under 4 seconds. > Mount with NFSv4 and it takes about the same. However: OK, that's interesting. I wonder what the problem is, then? I can't think of what else would make /home different. > drwxr-xr-x 2 4294967294 root 4096 Oct 8 16:19 2974 > drwxr-xr-x 2 4294967294 root 4096 Oct 8 16:19 2975 > drwxr-xr-x 2 4294967294 root 4096 Oct 8 16:19 2976 > drwxr-xr-x 2 4294967294 root 4096 Oct 8 16:19 2977 > drwxr-xr-x 2 4294967294 root 4096 Oct 8 16:19 2978 > drwxr-xr-x 2 u2979 root 4096 Oct 8 16:19 2979 > drwxr-xr-x 2 u2980 root 4096 Oct 8 16:19 2980 > drwxr-xr-x 2 4294967294 root 4096 Oct 8 16:19 2981 > drwxr-xr-x 2 4294967294 root 4096 Oct 8 16:19 2982 > drwxr-xr-x 2 4294967294 root 4096 Oct 8 16:19 2983 > drwxr-xr-x 2 4294967294 root 4096 Oct 8 16:19 2984 > drwxr-xr-x 2 4294967294 root 4096 Oct 8 16:19 2985 > drwxr-xr-x 2 4294967294 root 4096 Oct 8 16:19 2986 > .... Oops. > tcpdump shows the server is returning the write stuff, but something if going > wrong on the client. I've tried unmounting/remounting and killing/restarting > rpc.idmapd. > I had some config problems previously .. is there any chance that these > unknown entries are in a cache? Any easy way to view or flush the cache? Not that I know of. What client version is this, and is it using the new (nfsidmap) or old (idmapd) idmapper? --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
