Bug 790683 - vsftpd should be using portreserve
Summary: vsftpd should be using portreserve
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: vsftpd
Version: 6.2
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: rc
: ---
Assignee: Jiri Skala
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-02-15 07:50 UTC by Karel Srot
Modified: 2014-11-09 22:35 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-02-15 11:55:15 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Karel Srot 2012-02-15 07:50:01 UTC
To avoid port conflicts with services such as CUPS or IMAP 
vsftpd
should be using portreserve for reserving respective ports on RHEL6.


Typical changes required:

Given a SysV service package that uses a particular port, (say, krb5_prop/tcp -
754):

1) Create a file named after the service, for example 'krb5_prop', which
contains:

krb5_prop/tcp

2) In the spec, install this file in /etc/portreserve, i.e.,
/etc/portreserve/krb5_prop

3) In the spec, add 'Requires: portreserve' to the package that provides the
server.

4) In the init script, in the start() stanza, add:

    [ -x /sbin/portrelease ] && /sbin/portrelease krb5_prop &>/dev/null || :

before starting the daemon.


Some background can be found in bug 103401.

Comment 2 Karel Srot 2012-02-15 07:58:24 UTC
I forgot to mention that we are interested in ports withing the range 600 - 1023.

Comment 3 Jiri Skala 2012-02-15 11:55:15 UTC
The vsftpd communicates on port 21 with the client that uses port > 1024. There are handled ports for data transfer. This mechanism is the same for TLS too.

No one of that ports is in the range 600-1024. This could be done only by explicit setting in the vsftpd.conf file.

I didn't find any occurrence using port in the range 600-1024 by vsftpd. Therefore I close it with the status 'netabug'.


Note You need to log in before you can comment on or make changes to this bug.