2

I'm using ProFTPd 1.3.5a (btw I get the same behavior on an older 1.3.4d) with a pretty common virtual users setup for a web server.

In plain words, ProFTPd is running with apache's UID/GID and has its local files for authentication. All users have the same real UID/GID (again, apache's one) and are chrooted in their directories, with DirFake* entries.

This is an excerpt from configuration:

AuthPAM off
AuthOrder mod_auth_file.c
AuthUserFile /etc/proftpd/ftpd.passwd
AuthGroupFile /etc/proftpd/ftpd.group
UseFtpUsers off
DefaultRoot ~
DefaultChdir /
DirFakeUser on ~
DirFakeGroup on ~
DirFakeMode 0644
ShowSymLinks off
Umask 026 027

<Directory ~/>
  UserOwner www-data
  GroupOwner www-data
</Directory>

But with every ftp client I try, when listing files I only get numeric UID/GID and not the virtual user name. This is also annoying because clients such as CyberDuck will assume that numeric ID is not the same as the user they are connected with, and will show all files/directories as inaccessible (even if then trying to access them actually works).

edit: on the server there is a "real" user www-data with UID 33 and group www-data with GID 33, ProFTPd runs with that UID/GID, the virtual users in /etc/proftpd/ftpd.[passwd|group] all have uid=gid=33, all the files in the users directories have uid=gid=33. Right now ftp clients list all files as uid 33 and gid 33 and fail to convert numeric IDs to user / group names. I don't want to show files as belonging to www-data in ftp clients, but belonging to the user name they used to authenticate. This is also what the mod_ls would do with DirFake* options, as I understood it: throwing fake user/group to the connected clients. It isn't doing that or at least it is doing that just for the numeric IDs.

How can I let ProFTPd show the virtual user name in listings to clients?

  • 2
    Are files owned by "real users" i.e. those present in /etc/passwd also always shown as UID/GID numbers? Because that might indicate that ListOptions is set to -n – HBruijn Sep 30 '16 at 13:28
  • @HBruijn thanks for asking, I added that information to my original question. – Luke404 Oct 3 '16 at 13:18
  • @HBruijn there is no ListOptions in my config, and I even tried adding ListOptions +n to the <Directory> block but it did not have any effect. – Luke404 Oct 3 '16 at 13:21
  • 1
    Some FTP clients now use the newer MLSD/MLST commands, rather than LIST and NLST, for listing files; these newer commands don't have facts for the names, just the IDs. Thus you might try adding FactsAdvertise off to your proftpd.conf, which tells ProFTPD to not advertise that it can handle those newer FTP commands. This, in turn, should cause the FTP clients to fall back to the older FTP commands, which do provide the names. – Castaglia Oct 12 '16 at 15:12
  • @Castaglia that did the trick, thanks! You should post it as an answer! – Luke404 Oct 29 '16 at 20:08
2

Some FTP clients now use the newer MLSD/MLST commands, rather than LIST and NLST, for listing files; these newer commands don't have facts for the names, just the IDs. Thus you might try adding FactsAdvertise off to your proftpd.conf, which tells ProFTPD to not advertise that it can handle those newer FTP commands. This, in turn, should cause the FTP clients to fall back to the older FTP commands, which do provide the names.

Update: I've requested that two new OS-Specific Facts, UNIX.ownername and UNIX.groupname, be registered with the IANA for use in MLSD listings, to be able to provide the user/group names in listings using that command. I'll be adding support for these to ProFTPD soon.

Hope this helps!

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.