Conflicting assignment of priviledged ports on boot

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Conflicting assignment of priviledged ports on boot

Gernot Salzer

On boot some daemons (like nis/ypbind) obtain priviledged ports
via portmap/bindresvport(). Portmap assigns ports that are not in use
at the time of request, usually above 600. This strategy sometimes
conflicts with daemons that rely on fixed ports and that
start after ypbind (like cups, slapd): they find that their port
is already in use.
This problem is well known since at least two years, not just with Debian
but also with other Linux versions like Redhat [1,2].

Starting ypbind later during boot is no solution in general since some
services rely on ypbind AND fixed priviledged ports.
Possible solutions are:

- Modify portmap/bindresvport such that certain blacklisted
  ports are skipped even if they are not yet in use when a
  new priviledged port ist requested.

- Make use of a program like portreserve/portrelease [3].
  When the portreserve daemon is started, it examines the /etc/portreserve/
  directory. Each file not containing "." or "~" in its name is considered
  to be a service configuration file, and must contain a service name
  (as listed in /etc/services) or a port number. For example,
  /etc/portreserve/cups might contain the string "ipp".
  For each service configuration file, a socket is created and bound
  to the appropriate port. A service wishing to bind to its port must
  first run portrelease, which instructs portreserve to release the port
  associated with the service.

The second solution requires only a few changes to Debian:
- every daemon relying on a fixed port that might be affected by portmap
  has to drop a file in /etc/portreserve upon package installation.
  Furthermore, its init script has to call portrelease before the
  daemon is started.
- portreserve/portrelease has to be included with Debian.

I propose to modify Debian in this way.

Gernot

[1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103401
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=306465
[3] http://cyberelk.net/tim/portreserve/





--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Conflicting assignment of priviledged ports on boot

Henrique de Moraes Holschuh
On Fri, 23 Sep 2005, Gernot Salzer wrote:
> - Modify portmap/bindresvport such that certain blacklisted
>   ports are skipped even if they are not yet in use when a
>   new priviledged port ist requested.

Since the braindamaged one here is portmap, that's probably best. Modify it
to never use anything that has an entry in /etc/services.  If we have too
much crap on /etc/services, clean that up a bit.

> The second solution requires only a few changes to Debian:
> - every daemon relying on a fixed port that might be affected by portmap
>   has to drop a file in /etc/portreserve upon package installation.

Nice amount of filesystem bloat to support broken design here.

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Conflicting assignment of priviledged ports on boot

Bernd Eckenfels
In reply to this post by Gernot Salzer
In article <[hidden email]> you wrote:
> I propose to modify Debian in this way.

why not request a fixed port for ypbind?

Gruss
Bernd


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Conflicting assignment of priviledged ports on boot

Javier Fernandez-Sanguino-2
In reply to this post by Gernot Salzer
On Fri, Sep 23, 2005 at 02:36:55PM +0200, Gernot Salzer wrote:
> Starting ypbind later during boot is no solution in general since some
> services rely on ypbind AND fixed priviledged ports.
> Possible solutions are:
>
> - Modify portmap/bindresvport such that certain blacklisted
>   ports are skipped even if they are not yet in use when a
>   new priviledged port ist requested.

Portmap cannot be modified like that, as it only maps ports used by
applications, the applications themselves call bindresvport.
So this change actually means changing the libc which the libc maintainer
is against, and for good reasons (more rationale on RH's Buzgilla: #103401
and #154800).

FWIW, this bug has only been reported once (and reassigned to portmap)
see #261484 so its seems Debian users don't get beaten by this too often.

> I propose to modify Debian in this way.

Yes, probably portreserve is the way to go. Although it might make sense to
coordinate this with other distros. In any case, this means changing
a number of packages (cupsys, IMAP/POP3 daemons, Ldap daemons) that
need to use RPC services and start _after_ those in the init sequence.
Maybe when somebody goes ahead and adds initscripts dependencies, as suggested
by Petter Reinholdtsen for LSB 3.0 compliance, we can have a good
understanding of what packages would need to be changed.

Regards

Javier

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Conflicting assignment of priviledged ports on boot

Gernot Salzer
In reply to this post by Bernd Eckenfels
> why not request a fixed port for ypbind?

It is not ypbind that is broken but the service that hands out
the port numbers and that is called by ypbind (and by other
services). It just happens that most clashes occur in connection
with ypbind, due to its prominence and its place in the init sequence.

And modifying a library routine seems to be not so easy, see
Javier's post:
> Portmap cannot be modified like that, as it only maps ports used by
> applications, the applications themselves call bindresvport.
> So this change actually means changing the libc which the libc maintainer
> is against, and for good reasons (more rationale on RH's Buzgilla: #103401
> and #154800).

Gernot



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Conflicting assignment of priviledged ports on boot

Javier Fernandez-Sanguino-2
In reply to this post by Henrique de Moraes Holschuh
On Fri, Sep 23, 2005 at 10:20:21AM -0300, Henrique de Moraes Holschuh wrote:
> On Fri, 23 Sep 2005, Gernot Salzer wrote:
> > - Modify portmap/bindresvport such that certain blacklisted
> >   ports are skipped even if they are not yet in use when a
> >   new priviledged port ist requested.
>
> Since the braindamaged one here is portmap, that's probably best. Modify it
> to never use anything that has an entry in /etc/services.  If we have too
> much crap on /etc/services, clean that up a bit.

No, portmap is not the one braindmaged as it does _not_ assign ports, it only
registers them. Take a look at the FAM code:

src/Listener.c++
(...)
     95         if (bindresvport(sock, &addr) < 0)
     96         {
     97             Log::perror("can't bind to reserved port");
     98             exit(1);
     99         }
(...)
    105         (void) pmap_unset(program, version);
    106         if (!pmap_set(program, version, IPPROTO_TCP, ntohs(addr.sin_port    106 )))
    107         {
    108             Log::error("can't register with portmapper.");
    109             exit(1);
    110         }

The same is true for other RPC servers. It's the libc that restricts the port
numbers (look at glibc-2.3.5/sunrpc/bindrsvprt.c, currently, it seems
it's  port = (PID % 424) + 600). And, as I've said, the libc maintainer is
not going to add a blacklist there for stuff in /etc/services. Please reread
the references I gave in my previous e-mail.

Regards


Javier

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Conflicting assignment of priviledged ports on boot

Bernd Eckenfels-2
In reply to this post by Gernot Salzer
On Fri, Sep 23, 2005 at 04:11:03PM +0200, Gernot Salzer wrote:
> It is not ypbind that is broken but the service that hands out
> the port numbers and that is called by ypbind (and by other
> services). It just happens that most clashes occur in connection
> with ypbind, due to its prominence and its place in the init sequence.

Well, my idea is to fix only the rpc servers which cause trouble (ie.
started early). and if this is only ypbind it needs to be modified to use a
fixed port and register itself with pmap_set.

Some rpc servers allow to be bound to a fixed port anyway.

Gruss
Bernd


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Conflicting assignment of priviledged ports on boot

Henrique de Moraes Holschuh
In reply to this post by Javier Fernandez-Sanguino-2
On Fri, 23 Sep 2005, Javier Fernández-Sanguino Peña wrote:
> not going to add a blacklist there for stuff in /etc/services. Please reread
> the references I gave in my previous e-mail.

I shall.

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Reply | Threaded
Open this post in threaded view
|

Re: Conflicting assignment of priviledged ports on boot

Gernot Salzer
In reply to this post by Javier Fernandez-Sanguino-2

> FWIW, this bug has only been reported once (and reassigned to portmap)
> see #261484

No. See also
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=306465
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=257876
In each thread several people report of similar problems.

> so its seems Debian users don't get beaten by this too often.

It occurs (alomst) only during startup, and only if you run a service that
starts early in the boot sequence and calls bindresvport (like ypbind)
which is usually only the case with servers.
I was bitten several times, but usually I just restarted a few services
until it worked. Once the server ran there were no more problems.

Bottomline: not every user is affected, but some are, and once they
are affected, it is likely that the problem persists: the boot sequence
is rather deterministic, so the clash will likely reoccur with every
boot.

> Yes, probably portreserve is the way to go. Although it might make sense to
> coordinate this with other distros.

Well, the problem has been around since at least 2002, so I'd prefer to start
doing something about it.

> In any case, this means changing
> a number of packages (cupsys, IMAP/POP3 daemons, Ldap daemons) that
> need to use RPC services and start _after_ those in the init sequence.
> Maybe when somebody goes ahead and adds initscripts dependencies, as suggested
> by Petter Reinholdtsen for LSB 3.0 compliance, we can have a good
> understanding of what packages would need to be changed.

The nice thing about portreserve/portrelease is that we don't need to
have a good understanding. Modifying a package is safe: even if it starts
long before nis nothing bad happens if the port is handled by portreserve.
And if we miss to modify a package, we are no worse off than now.
In fact, we are better off, because we will have an address where to send
the bug report, namely to the package maintainer. Currently cups/ldap/...
blames nis, and nis/... blames portmap, portmap blames glibc, and there
are good reasons to leave glibc as it is.

Gernot



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Conflicting assignment of priviledged ports on boot

Loïc Minier
In reply to this post by Gernot Salzer
        Hi,

 This was already brought up to debian-devel.  This thread has more
 solutions, but addresses less problems: what if the service is to be
 started when the package is installed but a RPC programs already
 listens there?  The solution of shipping port reservations or of init
 dependencies won't help for this problem.  The only real option is to
 change libc/portmap/all RPC services to consult a blacklist of ports
 shipped in libc/portmap.

 <http://lists.debian.org/debian-devel/2004/10/threads.html#00292>

--
Loïc Minier <[hidden email]>


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Conflicting assignment of priviledged ports on boot

Gernot Salzer

>  This was already brought up to debian-devel.  This thread has more
>  solutions, but addresses less problems: what if the service is to be
>  started when the package is installed but a RPC programs already
>  listens there?  The solution of shipping port reservations or of init
>  dependencies won't help for this problem.

No, but it would help for most situations. With portreserve, the problem
would occur _only_ when installing a new service, but not after
reboots; moreover, it would occur only with _some_ installations, not
always. And finally, the installation script can locate the error
automatically (by checking whether the port is in use) and can suggest
the installer a solution. This seems to be acceptable (even though
this won't work with unsupervised installations).
The situation would be much better than now, since one can be sure
that once the service is installed, it will work in the future.

>  The only real option is to
>  change libc/portmap/all RPC services to consult a blacklist of ports
>  shipped in libc/portmap.

Waiting for this solution means that probably nothing will change for
the next few years, due to the side-effects of such a change.

portreserve/portrelease, on the other hand, makes things only better,
not worse; it does not interfere with the boot sequence as it is now,
is easy to implement, and it does not interfere with an optimal solution
where bindresvport takes care by itself.
Thus portreserve can bridge the time until agreement
has been reached about the optimal solution, and can be easily removed
then.

Waiting for all-or-nothing doesn't seem very attractive to me.

Gernot


Reply | Threaded
Open this post in threaded view
|

Re: Conflicting assignment of priviledged ports on boot

Mark brown-22
In reply to this post by Javier Fernandez-Sanguino-2
On Fri, Sep 23, 2005 at 04:02:41PM +0200, Javier Fernández-Sanguino Peña wrote:

> FWIW, this bug has only been reported once (and reassigned to portmap)
> see #261484 so its seems Debian users don't get beaten by this too often.

There's at least two people who have reported this against nis too.

--
"You grabbed my hand and we fell into it, like a daydream - or a fever."

signature.asc (316 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Conflicting assignment of priviledged ports on boot

Mark brown-22
In reply to this post by Bernd Eckenfels-2
On Fri, Sep 23, 2005 at 04:44:49PM +0200, Bernd Eckenfels wrote:

> Well, my idea is to fix only the rpc servers which cause trouble (ie.
> started early). and if this is only ypbind it needs to be modified to use a
> fixed port and register itself with pmap_set.

Most of the NIS services (including ypbind) already support this
although they aren't the only services which don't have a reserved port
to bind to.  The trick is picking suitable ports for them.

--
"You grabbed my hand and we fell into it, like a daydream - or a fever."

signature.asc (316 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Conflicting assignment of priviledged ports on boot

Joe Smith-10
In reply to this post by Javier Fernandez-Sanguino-2

"Javier Fernández-Sanguino Peña" <[hidden email]> wrote in message
news:[hidden email]...

>The same is true for other RPC servers. It's the libc that restricts the
>port
>numbers (look at glibc-2.3.5/sunrpc/bindrsvprt.c, currently, it seems
>it's  port = (PID % 424) + 600). And, as I've said, the libc maintainer is
>not going to add a blacklist there for stuff in /etc/services. Please
>reread
>the references I gave in my previous e-mail.

Um... libc *SHOULD NOT* be doing that.
A program should *NEVER* use a port in the range 1-1023 without registering
the port with the IANA's well known port list.

It is alsa a bad idea to use a port in the range of  1024-49151 without
registering.

If more privleged ports are needed it should be possible to have a system
reserve a small portion of the dynamic/privare address space. (Dynamic use
of ports outside this range is just asking for trouble.)
I suspect it is the RPC system that is brain-dead.



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Conflicting assignment of priviledged ports on boot

Mark brown-22
In reply to this post by Loïc Minier
On Fri, Sep 23, 2005 at 05:27:14PM +0200, Loïc Minier wrote:

>  dependencies won't help for this problem.  The only real option is to
>  change libc/portmap/all RPC services to consult a blacklist of ports
>  shipped in libc/portmap.

Given that none of the upstream libc maintainers who I've seen voice an
opinion appear to be in the slightest bit enthusiastic about such a
solution I would not be optimistic about the chances of it being
implemented and deployed in the immediate future.  See for example the
discussion at:

   https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103401

In an ideal world dynamic services would have a range of ports reserved
for them.  We're quite a way away from an ideal world here.

--
"You grabbed my hand and we fell into it, like a daydream - or a fever."

signature.asc (316 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Portreserve package alternative solution (was Re: Conflicting assignment of priviledged ports on boot)

Javier Fernandez-Sanguino-2
In reply to this post by Gernot Salzer
On Fri, Sep 23, 2005 at 04:54:56PM +0200, Gernot Salzer wrote:
>
> Well, the problem has been around since at least 2002, so I'd prefer to start
> doing something about it.

Ok, ok. Just for the sake of those being bitten by this bug I've made
portreserve packages and sent and ITP. Packages are currently available at
http://people.debian.org/~jfs/portreserve/

I'm ccing the bug submitters to have them test that solution and see if it
works for them. In any case, bugs might need to be merged and/or renamed to
wishlist once portreserve is available. All the steps on how to avoid this
issue using portreserve are described in the upstream README file and
Debian's README.Debian file in the package.

We also need to coordinate with other distros (such as Red Hat or SuSE).

Regards

Javier

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Conflicting assignment of priviledged ports on boot

Joe Smith-10
In reply to this post by Mark brown-22

"Mark Brown" <[hidden email]> wrote in message
news:[hidden email]...
>In an ideal world dynamic services would have a range of ports reserved
>for them.  We're quite a way away from an ideal world here.
There are ports for that.
All ports above 49151 are designated for local (i.e. client) or dynamic
(i.e. dynamic servers) use.

People usually think of that as the client range, but actually it is NOT
intended to be restricted to clients.



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Conflicting assignment of priviledged ports on boot

Javier Fernandez-Sanguino-2
On Sat, Sep 24, 2005 at 09:33:17PM -0400, Joe Smith wrote:
>
> "Mark Brown" <[hidden email]> wrote in message
> news:[hidden email]...
> >In an ideal world dynamic services would have a range of ports reserved
> >for them.  We're quite a way away from an ideal world here.
> There are ports for that.
> All ports above 49151 are designated for local (i.e. client) or dynamic
> (i.e. dynamic servers) use.

Those cannot be used for some RPC server services as some need to run on
"trusted" ports (i.e. <1024) for servers to work together fine. Yes,
not really "trusted" this day and age, but actually necessarily for
compatibity reasons with other (legacy?) UN*X services.

Regards

Javier

signature.asc (196 bytes) Download Attachment