All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jim Rees <rees@umich.edu>
To: Mi Jinlong <mijinlong@cn.fujitsu.com>
Cc: Steve Dickson <SteveD@redhat.com>,
	NFS <linux-nfs@vger.kernel.org>,
	Chuck Lever <chuck.lever@oracle.com>
Subject: Re: [PATCH v2] rpc.mountd: let mountd consult /etc/services for port
Date: Sat, 28 May 2011 09:29:53 -0400	[thread overview]
Message-ID: <20110528132953.GA8525@merit.edu> (raw)
In-Reply-To: <4DE0C380.7040608@cn.fujitsu.com>

Mi Jinlong wrote:

  At RHEL, if user set port for mountd at /etc/services as 
  "mount   12345/tcp", mountd should be bind to 12345, but the 
  latest nfs-utils, mountd get a rand port, not 12345.
  
  This patch make sure mountd be bind to the port which was set
  at /etc/service.

Is this really such a good idea?  I would find this behavior surprising.  I
expect listeners to either use a well-known port, in which case they look in
/etc/services and fall back to a compiled-in constant (like telnet or ftp),
or use an ephemeral port, in which case they don't even look at
/etc/services.  This patch would change mountd so that its behavior
(well-known versus ephemeral) depends on /etc/services rather than a
run-time option.

The change in behavior would not be immediately obvious, either, because who
is going to notice that mountd is now on a well-known port?

You could argue that the admin would have to add a line to /etc/services for
anything to change, and I guess I could be convinced.  But are you sure some
distro packaging person isn't going to put that line in without
understanding the implications?

Yes, I know putting mountd on a random port isn't going to thwart a
determined hacker.  I'm thinking of the nuisance factor.  Consider ssh.
It's a secure protocol, so there isn't really a security risk with leaving
it on port 22, but sometimes you have to move it off to keep the log files
from filling up with crap.

Here's an alternate proposal.  Have the "-p" option take either a number or
a name.  If it's a name, look it up in /etc/services.

  reply	other threads:[~2011-05-28 13:29 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-19  8:33 [PATCH] svc: make sure mountd can get ports from /etc/services Mi Jinlong
2011-04-19 13:28 ` Chuck Lever
2011-04-20  9:29   ` Mi Jinlong
2011-04-20 15:08     ` Chuck Lever
2011-04-21  3:42       ` Mi Jinlong
2011-04-21 14:11         ` Chuck Lever
2011-04-25  7:09           ` Mi Jinlong
2011-04-25 15:58             ` Chuck Lever
2011-05-28  9:42 ` [PATCH v2] rpc.mountd: let mountd consult /etc/services for port Mi Jinlong
2011-05-28 13:29   ` Jim Rees [this message]
2011-05-28 16:01     ` Chuck Lever
2011-05-28 16:45       ` Jim Rees
2011-06-07 20:17         ` Steve Dickson
2011-06-10  8:23           ` Mi Jinlong
2011-08-03 17:52   ` Steve Dickson

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=20110528132953.GA8525@merit.edu \
    --to=rees@umich.edu \
    --cc=SteveD@redhat.com \
    --cc=chuck.lever@oracle.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=mijinlong@cn.fujitsu.com \
    /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.