Hi,
On Thu, Dec 08, lista unx wrote:
> To be simple for everyone, I've changed configuration file with one very
> simple (few lines) and repeat tests. The problem remain. LIST is stalled!
>
> [root@... alex]# telnet 192.168.13.104 21
telnet is not a ftp client.
For file listing or file transfer a data connections is needed.
So please try a real ftp client and then the LIST should work.
--
Regards
Dieter Bloms
--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
>From field.

http://bugs.proftpd.org/show_bug.cgi?id=4169
We're investigating this and it still seems like it's exploitable on
1.3.6rc2. I just ran through the same steps in the above link on a freshly
rolled 1.3.6rc2 and it copied /etc/passwd to /tmp/passwd.copy
Looking at the git commits, the entry that says it fixes 4169 doesn't have
any code that seems to be related (there's a single mod_sftp patch).

I removed Masquerade, which has been just a try. I can confir, Behaviour is
the same: with or WITHOUT masquerade address. LIST command is stalled!
----- Original Message -----
From: "TJ Saunders" <tj@...>
To: "Lista Unx" <lista.unx@...>; <proftp-user@...>
Sent: Wednesday, December 07, 2016 6:19 PM
Subject: Re: [Proftpd-user] LIST command stalled - proftpd not listing
content
>
>
> On Wed, Dec 7, 2016, at 04:07, Lista Unx wrote:
>> Hello all,
>>
>> Trying to isolate a global problem which I have on another system, I've
>> installed proftpd on centos 7 box, standalone. From the beginning Selinux
>> and firewall has been disabled!
>>
>> When trying to connect locally and LIST content in current path, nothing
>> is displayed and the process is still running in loop.
>
>> [root@... alex]# telnet localhost 21
>> Trying 127.0.0.1...
>> Connected to localhost.
>
> Here you contact your FTP server on 127.0.0.1 for the control
> connection.
>
>> pasv
>> 227 Entering Passive Mode (192,168,13,104,194,82).
>
> And here you requested a passive data transfer. The server responded
> with
> address 192.168.13.104, instructing the FTP client to contact that
> address
> for the requested data. This is a little odd, since normally the FTP
> server
> should tell the client to connect to the same IP address for data
> transfers
> as for the initial control connection...
>
>> See below my proftpd.conf
>>
>> [root@... alex]# cat /etc/proftpd.conf
>
>> MasqueradeAddress 192.168.13.104
>
> And here, with this MasqueradeAddress, we see WHY your server is telling
> your client to use the "wrong" IP address.
>
> I suspect that you will need to use a <VirtualHost> section for your WAN
> address -- and in that <VirtualHost> section, that's where you would use
> that
> MasqueradeAddress directive, so that it applied only to connections
> which used
> the WAN address.
>
> For LAN connections, you probably do NOT want to use a
> MasqueradeAddress; this
> might help:
>
> http://www.proftpd.org/docs/howto/NAT.html
>
> Cheers,
> TJ
>

On Wed, Dec 7, 2016, at 04:07, Lista Unx wrote:
> Hello all,
>
> Trying to isolate a global problem which I have on another system, I've
> installed proftpd on centos 7 box, standalone. From the beginning Selinux
> and firewall has been disabled!
>
> When trying to connect locally and LIST content in current path, nothing
> is displayed and the process is still running in loop.
> [root@... alex]# telnet localhost 21
> Trying 127.0.0.1...
> Connected to localhost.
Here you contact your FTP server on 127.0.0.1 for the control
connection.
> pasv
> 227 Entering Passive Mode (192,168,13,104,194,82).
And here you requested a passive data transfer. The server responded
with
address 192.168.13.104, instructing the FTP client to contact that
address
for the requested data. This is a little odd, since normally the FTP
server
should tell the client to connect to the same IP address for data
transfers
as for the initial control connection...
> See below my proftpd.conf
>
> [root@... alex]# cat /etc/proftpd.conf
> MasqueradeAddress 192.168.13.104
And here, with this MasqueradeAddress, we see WHY your server is telling
your client to use the "wrong" IP address.
I suspect that you will need to use a <VirtualHost> section for your WAN
address -- and in that <VirtualHost> section, that's where you would use
that
MasqueradeAddress directive, so that it applied only to connections
which used
the WAN address.
For LAN connections, you probably do NOT want to use a
MasqueradeAddress; this
might help:
http://www.proftpd.org/docs/howto/NAT.html
Cheers,
TJ

On Fri, Dec 2, 2016, at 04:11, Matus UHLAR - fantomas wrote:
> I have applied this patch to proftpd-1.3.5 (a few rejects applied
> manually),
> but after runnind "mlsd" multiple times (luckily tnftp supports this
> command) I still have the same problem.
>
> after further diggging (should have done this previously, just needed to
> get user's pasword), seems that this bug appears when mod_facl is loaded.
> Even turning "FaclEngine off" did not help.
Ah, that's very helpful. Thank you!
Based on that pointer, I've dug into the mod_facl code more closely, and
indeed saw the memory leaks. I've created a pull request which fixes
the issue:
https://github.com/proftpd/proftpd/pull/357
And I've verified the fix using Valgrind. While there, I also fixed the
handling of the FACLEngine directive to do what you'd want/expect here.
I'll be merging this PR shortly, and backporting it to the 1.3.5 branch.
Cheers,
TJ

Hello,
On 16.11.16 14:54, TJ Saunders wrote:
>When handling the MSLD command, the mod_facts module would use the
>command's temporary memory pool for the handling of ALL entries in the
>directory being listed. This means that for a wide directory, that
>temporary memory pool could grow quite large, before the handling of
>that command is completed. Once completed, that memory pool is "freed"
>-- which, in ProFTPD's case, simply means that the pool is made
>available for re-use later. It is not necessary released back to the
>operating system.
>
>When looking into this issue last week, I noticed the above behavior,
>and changed the mod_facts behavior (in the master branch on GitHub) so
>that a new temporary memory pool is allocated *per directory entry*,
>then freed up after that entry. This should help keep the memory usage
>lower for wide directories. See:
>
> https://github.com/proftpd/proftpd/commit/25dffc6dea2b0c478d539e5fa9b46bd20f965d25
>
>Thus if you can, you might try getting the proftpd source from master,
>recompiling, and testing/verifying.
I have applied this patch to proftpd-1.3.5 (a few rejects applied manually),
but after runnind "mlsd" multiple times (luckily tnftp supports this
command) I still have the same problem.
after further diggging (should have done this previously, just needed to get
user's pasword), seems that this bug appears when mod_facl is loaded.
Even turning "FaclEngine off" did not help.
--
Matus UHLAR - fantomas, uhlar@... ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
BSE = Mad Cow Desease ... BSA = Mad Software Producents Desease

On Mon, Nov 28, 2016, at 10:07, Patel, Viren wrote:
> Hello. I have configured ProFTPD 1.3.5/mod_sftp to allow users to sftp to
> the server using SSH keys. Everything works as expected except for
> creating folders. The users can login, upload files using put, and can
> also delete existing files *and* folders. However the users cannot create
> a new folder using mkdir or via put –r.
> SFTPLog /opt/proftpd/var/log/sftp.log
> ExtendedLog /opt/proftpd/var/log/sftp_extended.log
What do these SFTPLog and ExtendedLog files show, for the client in
question? In particular, I'm hoping to see the specific SFTP requests
(and order) used by the client...
> Running the server with –d 10 option the following messages are in the
> system log file when mkdir command is issued:
>
> dispatching PRE_CMD command 'MKDIR /ppp' to mod_core
> dispatching PRE_CMD command 'MKDIR /ppp' to mod_core
> dispatching PRE_CMD command 'MKD /ppp' to mod_core
> dispatching PRE_CMD command 'MKD /ppp' to mod_core
> in dir_check_full()
> in dir_check_full()
> chmod(/.dstXXXrb5R2u) failed
Is the user's home directory located on some network-mounted filesystem,
e.g. NFS or SMB or somesuch?
Cheers,
TJ

On 18.11.16 12:55, Peter Irbizon wrote:
>Hello, I would like to ask you for help with this - I am currently using
>login credential name to my ftp as "user". But I would like to use
>user.domain.com instead of user.
>
>How could I set this in proftpd?
>(I ma using linux debian)
users log in using their usernames. You need to create user
"user.domain.com" and they'll be able to log using this username.
--
Matus UHLAR - fantomas, uhlar@... ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
A day without sunshine is like, night.

Hello, I would like to ask you for help with this - I am currently using
login credential name to my ftp as "user". But I would like to use
user.domain.com instead of user.
How could I set this in proftpd?
(I ma using linux debian)
Many thanks

> On 13.11.16 13:56, TJ Saunders wrote:
> >> Which has approximately how many files/entries in it?
>
> 65968 files currently. I can try to reproduce the issue with the same
> account, if needed.
OK. That helps.
When handling the MSLD command, the mod_facts module would use the
command's temporary memory pool for the handling of ALL entries in the
directory being listed. This means that for a wide directory, that
temporary memory pool could grow quite large, before the handling of
that command is completed. Once completed, that memory pool is "freed"
-- which, in ProFTPD's case, simply means that the pool is made
available for re-use later. It is not necessary released back to the
operating system.
When looking into this issue last week, I noticed the above behavior,
and changed the mod_facts behavior (in the master branch on GitHub) so
that a new temporary memory pool is allocated *per directory entry*,
then freed up after that entry. This should help keep the memory usage
lower for wide directories. See:
https://github.com/proftpd/proftpd/commit/25dffc6dea2b0c478d539e5fa9b46bd20f965d25
Thus if you can, you might try getting the proftpd source from master,
recompiling, and testing/verifying.
Hope this helps,
TJ

>> > >How large (i.e. how many files/entries) are the directories being listed
>> > >via MLSD? On the order of hundreds/thousands?
>> >
>> > it was the "protokoly" directory.
On 13.11.16 13:56, TJ Saunders wrote:
>> Which has approximately how many files/entries in it?
65968 files currently. I can try to reproduce the issue with the same
account, if needed.
>> > client was uploading and downloading
>> > files, running mlsd once in a while. after 3 hours the memory usage grown
>> > to the one shown above.
>> >
>> > during each mlsd the memory usage increased...
>>
>> Could you provide the debug logging for that session, to see the full
>> commands/responses used, so that we can better try to recreate the issue
>> locally?
I have turned on extended logging
("ExtendedLog /var/log/proftpd/extended ALL full")
after I noticed the issue
(the commands I saw were captured by wireshark).
>Could you also provide the output of `proftpd -V`, and the proftpd.conf
>you're using please, so that I can make sure to test with a proftpd
>built and configured the same way?
standard debian 8/amd64 proftpd
disabled radius, quotatab, memcache modules, enabled and configured tls
--
Matus UHLAR - fantomas, uhlar@... ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"They say when you play that M$ CD backward you can hear satanic messages."
"That's nothing. If you play it forward it will install Windows."

Hi,
I want to update my ProFTPD version from 1.3.3 to version 1.3.6rc2. My ProFTPD version runs with mod_clamav 0.11 and everything is fine. Unfortunately is doesn't work with 1.3.6rc2 and mod_clamav 0.11. Does someone has instructions how to get it work with 1.3.6rc2 and mod_clamav?
Thanks Olli

> > >How large (i.e. how many files/entries) are the directories being listed
> > >via MLSD? On the order of hundreds/thousands?
> >
> > it was the "protokoly" directory.
>
> Which has approximately how many files/entries in it?
>
> > client was uploading and downloading
> > files, running mlsd once in a while. after 3 hours the memory usage grown
> > to the one shown above.
> >
> > during each mlsd the memory usage increased...
>
> Could you provide the debug logging for that session, to see the full
> commands/responses used, so that we can better try to recreate the issue
> locally?
Could you also provide the output of `proftpd -V`, and the proftpd.conf
you're using please, so that I can make sure to test with a proftpd
built and configured the same way?
Thanks,
TJ

On Sun, Nov 13, 2016, at 03:29, Matus UHLAR - fantomas wrote:
> >How large (i.e. how many files/entries) are the directories being listed
> >via MLSD? On the order of hundreds/thousands?
>
> it was the "protokoly" directory.
Which has approximately how many files/entries in it?
> client was uploading and downloading
> files, running mlsd once in a while. after 3 hours the memory usage grown
> to the one shown above.
>
> during each mlsd the memory usage increased...
Could you provide the debug logging for that session, to see the full
commands/responses used, so that we can better try to recreate the issue
locally?
Cheers,
TJ

>> On 10.11.16 14:02, Matus UHLAR - fantomas wrote:
>> >I'm running proftpd 1.5 under debian jessie.
>> >
>> >one client has triggered huge memory usage after 4 hours of running:
>> >
>> >23211 username 20 0 7299676 4.717g 4116 S 0.0 61.7 8:01.00 proftpd
[...]
>> >drwxr-xr-x 2 username users 2244608 Nov 10 13:51 ./protokoly
>> >
>> >any idea how to track memory usage in proftpd?
On 12.11.16 17:01, TJ Saunders wrote:
>One way in which I start tracking down this sort of thing is use
>'ftpdctl debug memory', assuming that proftpd has been compiled with
>--enable-devel and the mod_ctrls_admin module; see:
>
> http://www.proftpd.org/docs/contrib/mod_ctrls_admin.html#debug
>
>This will cause the process to give a debug dump of the various memory
>pools ProFTPD is using. This method, however, is usually best done when
>the issue can be reproduced locally, using a special build of proftpd,
>rather than used on a running production system.
>
>> after watching the tshark's outout, seems that process size increases any
>> time MSLD is issued.
>
>How large (i.e. how many files/entries) are the directories being listed
>via MLSD? On the order of hundreds/thousands?
it was the "protokoly" directory. client was uploading and downloading
files, running mlsd once in a while. after 3 hours the memory usage grown to
the one shown above.
during each mlsd the memory usage increased...
>What tools/commands are you using to measure memory usage? top? ps?
the output above is from top. I got to this issue because monitoring
notified us with too huge memory usage.
--
Matus UHLAR - fantomas, uhlar@... ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Silvester Stallone: Father of the RISC concept.

4 messages has been excluded from this view by a project administrator.

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details