All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@poochiereds.net>
To: Neil Brown <neilb@suse.de>
Cc: nfs@lists.sourceforge.net
Subject: Re: [PATCH 0/2] mountd: clean up rmtab handling
Date: Mon, 04 Dec 2006 10:05:17 -0500	[thread overview]
Message-ID: <4574392D.9080807@poochiereds.net> (raw)
In-Reply-To: <17779.42545.642976.873602@cse.unsw.edu.au>

Neil Brown wrote:
> 
> I'm not convinced... I don't like the idea of mapping an IP address to
> a hostname and then just working with the hostname.  Because it is
> really IP addresses that you trust, not host names (in the case of
> multi-homed hosts particularly).
> 

The patch I posted doesn't do that though. Perhaps I didn't explain it 
well enough...

All that patch does is get rid of the caching of the hostname list in 
my_client. Currently, what happens is that we build a comma separated 
list of "hostnames" and stuff that into my_client.m_hostname. We build 
this comma-separated list via client_compose, which just calls 
client_check repeatedly to see what hostnames this address matches.

The patch I posted still uses the exact same decision making process to 
see if an address matches an nfs_client entry (client_check). It just no 
longer does this in two stages via the comma-separated list.

The patch I posted should make no change in behavior of whether a host 
is allowed or denied, aside from the particular case that we already 
discussed where a cached my_client hostname list is no longer correct.

All that said, I'm OK with pulling this info out of the kernel caches 
instead. I'll have a look over the latest patch that you sent and see if 
it does what we need.

Thanks,
Jeff

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

  parent reply	other threads:[~2006-12-04 15:05 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-25 13:07 [PATCH 0/2] mountd: clean up rmtab handling Jeff Layton
2006-12-01 15:29 ` Jeff Layton
2006-12-04  4:38   ` Neil Brown
2006-12-04  6:33     ` Neil Brown
2006-12-05  2:28       ` Jeff Layton
2006-12-05  2:51         ` Jeff Layton
2006-12-09 12:27           ` Jeff Layton
2006-12-04 15:05     ` Jeff Layton [this message]
2006-12-11  1:00       ` Neil Brown
2006-12-11  3:40         ` Jeff Layton
2006-12-12  1:07           ` Neil Brown
2006-12-12  7:52             ` Warren Beldad
2006-12-13 13:17             ` Jeff Layton

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=4574392D.9080807@poochiereds.net \
    --to=jlayton@poochiereds.net \
    --cc=neilb@suse.de \
    --cc=nfs@lists.sourceforge.net \
    /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.