vsftpd max username length too small

Debdiff for jaunty which reflects the FC10 patch which has been incorporated upstream in version 2.1

Hi Kenny,

Now that karmic is out, should this be handled by merging vsftpd 2.1.1~pre1-1 from Debian rather than applying further patches to the 2.0.7 package we currently have in Ubuntu?

@Steve:

Thanks for looking at this bug. Yes, merging that revision from Debian would solve the issue for karmic (and indeed resolve this bug).

Would it be possible to nominate this debdiff for SRU to Hardy? Since I believe it fulfils the requirements of:-

a) non-critical package
b) very minimal patch
c) obviously safe

The reason I'd like to nominate for Hardy is that like I presume a fair few people / companies do we have our servers tracking the LTS releases of Ubuntu and as such it would be nice to have this this bug resolved on our (and indeed others') live hosting servers.

Thanks!

This bug was fixed in the package vsftpd - 2.1.1~pre1-2ubuntu1

---------------
vsftpd (2.1.1~pre1-2ubuntu1) karmic; urgency=low

  * Merge from Debian unstable. Remaining changes:
     - Use LSB functions in the init script
     - Use snakeoil SSL certificate and key
     - Do not create rc.d stop symlinks
     - Add update-inetd dependency
  * Dropped postinst change removing rc.d stop symlinks, was only useful for
    edgy and hardy upgrades
  * This upload includes changes closing a few bugs:
     - New upstream release (LP: #333478)
     - Call adduser with --quiet in postinst (LP: #272084)
     - Extend username length limit (LP: #343738)

vsftpd (2.1.1~pre1-2) unstable; urgency=medium

  * Correcting wrong charset definition in Galizian debconf translations
    (Closes: #524251).
  * Adding patch to not hardcode libcap soname (Closes: #526792).

vsftpd (2.1.1~pre1-1) unstable; urgency=low

  * Adding French debconf translations from Steve Petruzzello <email address hidden>
    (Closes: #522736).
  * Merging upstream version 2.1.1~pre1.
  * Applying patch from debian-l10n-english to improve debconf templates
    (Closes: #520592).
  * Adding updated German debconf translations from Helge Kreutzmann
    <email address hidden> (Closes: #522958).
  * Adding updated Swedish debconf translations from Martin Bagge
    <email address hidden> (Closes: #522977).
  * Adding Finnish debconf translations from Esko Arajarvi <email address hidden>
    (Closes: #522999).
  * Adding Russian debconf translations from Yuri Kozlov <email address hidden>
    (Closes: #523123).
  * Adding updated Japanese debconf translations from Hideki Yamane
    <email address hidden> (Closes: #523324).
  * Adding Spanish debconf translations from Fernando Gonzalez de Requena
    <email address hidden> (Closes: #523395).
  * Adding Galizian debconf translations from Marce Villarino
    <email address hidden> (Closes: #524251).

vsftpd (2.1.0-2) unstable; urgency=medium

  * Adding simplified Chinese debconf translations from Deng Xiyue
    <email address hidden> (Closes: #521790).
  * Adding updated Portuguese debconf translations from Miguel Figueiredo
    <email address hidden> (Closes: #522495).
  * Adding Japanese debconf translations from Hideki Yamane
    <email address hidden> (Closes: #522601).
  * Adding Italian debconf translations from Vincenzo Campanella
    <email address hidden> (Closes: #522603).

vsftpd (2.1.0-1) unstable; urgency=low

  * Merging upstream version 2.1.0 (Closes: #520779).
  * Rediffing config.patch.
  * Removing wifexited-const.patch, went upstream.
  * Removing defs.patch, went upstream.
  * Renumbering db-doc.patch.

vsftpd (2.0.7-4) unstable; urgency=low

  * Adding Portuguese debconf translations from Americo Monteiro
    <email address hidden> (Closes: #516547).
  * Adding Swedish debconf translations from Martin Bagge <email address hidden>
    (Closes: #516682).
  * Simplyfing defaults handling of debconf variables in postinst script.
  * Adding German debconf translation from Kai Wasserbaech
    <email address hidden> (Closes: #517845).
  * Correcting wrong account name capitalization in German debconf translation.
  * Starting vsftpd wit...

Any chance of an explanation for the denial for hardy (denied by "Thierry Carrez")

I am also a hosting company and since 6.06 we've had to patch this ourselves.. we are now building new servers with 8.04 and find ourselves doing it again - I'm sure we're not in that small a minority.

Hey Trent,

Nominations for server-related bugs are discussed weekly at the Ubuntu Server team meeting [1]. This issue was considered an additional feature (support for usernames of more than 32 characters) rather than a bug, thus failing to reach the criteria for SRU.

[1] https://wiki.ubuntu.com/ServerTeam/Meeting

Thierry - thanks for the response. Is it possible to reconsider it? Because it's not like vsftpd has its own usernames it's using the systems user database.. so essentially vsftpd doesn't allow existing users to login that other software does - this happens commonly in web hosting when usernames are the same as a domain name. 32 character domain names are not uncommon.

If not, oh well - thanks for the response - much appreciated.

Sure, I'll bring it up at the next meeting (tomorrow).

I'd just like to add that (as the original bug reporter) I agree with Trent entirely. I can setup accounts (longer than 32 characters) that work just fine with PAM (and etc...) yet vsftpd fails to authenticate with them.

Although I can accept it's a somewhat grey area in this case between bug and feature request...

Can it be taken into account that the fix is obviously safe, has been applied by other distro's in their packages and even pulled into the vsftpd codebase itself?

Thanks Thierry :-)

The list of criteria for a Stable Release Updates are listed in the following wiki page:

https://wiki.ubuntu.com/StableReleaseUpdates#When

Which category would this bug fall in?

@Mathias

In my opinion I would think:-

"""
Bugs which do not fit under above categories, but (1) have an obviously safe patch and (2) affect an application rather than critical infrastructure packages (like X.org or the kernel).
"""

On Mon, Aug 24, 2009 at 07:03:14PM -0000, Kenny Millington wrote:
> """
> Bugs which do not fit under above categories, but (1) have an obviously safe patch and (2) affect an application rather than critical infrastructure packages (like X.org or the kernel).
> """

Probably. Next step is to find the "obviously safe patch" and attach it
to this bug.

--
Mathias Gug
Ubuntu Developer http://www.ubuntu.com

@Mathias:

You make an excellent point. Oversight on my part not realising I'd only prepared a jaunty diff and not a hardy one for SRU.

I've re-based the jaunty diff against hardy and attached it to the bug (as well as pushing it to my PPA for testing purposes).

Patch seems obvious enough. Accepting for hardy.

Next step is to prepare a proper SRU report:

https://wiki.ubuntu.com/StableReleaseUpdates#Procedure

Update the bug report description and make sure it contains the following information:

   1. A statement explaining the impact of the bug on users and justification for backporting the fix to the stable release
   2. An explanation of how the bug has been addressed in the development branch, including the relevant version numbers of packages modified in order to implement the fix.
   3. A minimal patch applicable to the stable version of the package. If preparing a patch is likely to be time-consuming, it may be preferable to get a general approval from the SRU team first.
   4. Detailed instructions how to reproduce the bug. These should allow someone who is not familiar with the affected package to reproduce the bug and verify that the updated package fixes the problem. Please mark this with a line "TEST CASE:".
   5. A discussion of the regression potential of the patch and how users could get inadvertently affected.

Just spotted a slight error in my debdiff. I made my debdiff against 2.0.6-1ubuntu1, failing to notice the -ubuntu1.1 in hardy-updates.

I'll submit an updated patch/debdiff later today against -ubuntu1.1 if someone else doesn't do so before hand.

TESTING NOTE: Please note that although the version in my PPA is fine to test with - it will regress #254905 (FTPS doesn't work with clients such as FileZilla).

Apologies for the mix up...

Updated patch attached to bug, old one removed (and new testing package pushed to my PPA). :-)

Uploaded to hardy-proposed with minor fixes to changelog (distro should be hardy-proposed, version should be 2.0.6-1ubuntu1.2)

Has it been confirmed that hardy's PAM version gets along with long usernames, too? Was it checked that hardy's vsftp version does not make assumptions about the user name lenght at any different place, such as string copy operations, file formats, and the like?

Patch was originally an FC10 patch applied to 2.0.5 that has been merged upstream as of 2.0.7. So it applies to hardy's version (2.0.6), and username length doesn't require to be patched elsewhere in upstream code.

On the hardy PAM getting along with those long usernames, no, that was not tested on my side, I just checked the patch, its upstream history, built and sponsored the upload. Maybe Kenny can confirm the testing from his PPA...

Martin: Feel free to reject this upload based on regression risk vs. severity of bug.

Did anyone ACK 2.0.6-1ubuntu1.2 in hardy-proposed yet? If not, consider this an ACK from ubuntu-sru; the patch looks reasonable. Thanks!

I'd like to double check this again before confirming hardy PAM is ok with usernames of this length but unfortunately I seem to have lost/deleted the test VM where I had this issue setup.

I'll re-create the VM and re-test this issue just to be sure (give me a couple of days or so depending on workload).

(Unless ofcourse Trent can provide such a confirmation.)

Any update on this Kenny?

Timing out for now. Please reopen if you still want to pursue this (but it's not quite in the range of SRUs really)