Re: [Proftpd-user] Limit, Limit WRITE, and protecting directories from rename

> Thus I was surprised upon moving on to the next testing that the
> WRITE command group used with Limit includes only RNTO.  In my
> testing I verified that both RNFR and RNTO were required, as rename
> can be used to move a subdirectory out _from_ a directory, simulating
> the effect of rmdir.

The specific reason for this, I believe, is that to effect a rename, an
FTP client must send RNFR, followed by RNTO.  The actual renaming of the
file/directory occurs during the handling of RNTO (in proftpd, anyway),
hence why RNTO is in the WRITE group.  The handling of RNFR does little
more than set up the state within the session information.

That said, I can't see why adding RNFR to the WRITE group would be a bad
thing; it would return an error to the FTP client earlier, if that
command was limited.  Care to open a request for this on bugs.proftpd.org?

> Also I'd like to note the perhaps less obvious point that restricting
> MKD/XMKD/RMD/XRMD has absolutely no effect on directory renaming,
> even though a rename may have the same effect.  How could that be
> mentioned in the documentation? (without confusion, that is)

I'll add this note to the FAQ section of the Limit documentation.

> the restricted directory.  That is, even if RNTO was restricted, you
> could rename into the restricted directory from the home
> directory.  How should that be described, as bug or misunderstood feature?

There's a longstanding issue with regard to .ftpaccess files, and how any
configurations in them are enforced.  It is related to how proftpd

[Proftpd-user] Wierd Problem

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

_______________________________________________
ProFTPD Users List   <proftpd-users <at> proftpd.org>
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html

[Proftpd-user] FW: Wierd Problem

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

_______________________________________________
ProFTPD Users List   <proftpd-users <at> proftpd.org>
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html

Re: [Proftpd-user] Wierd Problem

On Oct 1, 2007, at 5:39 PM, Jorge Bastos wrote:

> TJ,
>
> I have a situation that i don't see nothing relevant in the log.
>
> I've done the log with:
>
> ---
>
> /usr/local/sbin/proftpd -c /etc/proftpd.conf -nd10 2>&1 >& /home/ 
> alojamento/my_user/proftpd.txt
>
> ---
>
>
>
> in the first send, it's a file with about 6MB~, it sends it, and in  
> the end, it completed the send, but the MSDOS ftp client,it stops  
> for about 30 seconds and  gives-me the info below:
>
>
>
> ---
>
> ###################################################################### 
> ##########
> ##############
> Connection closed by remote host.
>
> ---
>
>
>
> if i connect the ftp again, and send a smaller file, it completes  
> all perfect.
>
>
>
> If i go and send the 6MB~ file again, but with the filezilla  
> windows client, when it gets the end, it stops also about around 30  
> seconds and after it finished.
>
>
>
> In the logs i don't see nothing that indicates error or something.
>
> How can i debug this more?

Is there anything such as a firewall or NAT/PAT device between the  
client and the server?    Could be something timing out there.

Could tcpdump and  look at both the data and the command channels on  
both client and server and compare what you see.

-Patrick

--
Patrick Muldoon
Network/Software Engineer
INOC (http://www.inoc.net)
PGPKEY (http://www.inoc.net/~doon)
Key ID: 0x370D752C

Printed on 100% recyclable phosphor.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
ProFTPD Users List   <proftpd-users <at> proftpd.org>
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html

Re: [Proftpd-user] Wierd Problem

Yes there's a NAT on the client side, but i belive it's not that, in fact it
can't.
That happens with the 6MB~ file, but not with the 600Kb one.

-----Original Message-----
From: proftp-user-bounces <at> lists.sourceforge.net
[mailto:proftp-user-bounces <at> lists.sourceforge.net] On Behalf Of Patrick
Muldoon
Sent: terça-feira, 2 de Outubro de 2007 1:40
To: proftp-user <at> lists.sourceforge.net
Subject: Re: [Proftpd-user] Wierd Problem

On Oct 1, 2007, at 5:39 PM, Jorge Bastos wrote:

> TJ,
>
> I have a situation that i don't see nothing relevant in the log.
>
> I've done the log with:
>
> ---
>
> /usr/local/sbin/proftpd -c /etc/proftpd.conf -nd10 2>&1 >& /home/ 
> alojamento/my_user/proftpd.txt
>
> ---
>
>
>
> in the first send, it's a file with about 6MB~, it sends it, and in  
> the end, it completed the send, but the MSDOS ftp client,it stops  
> for about 30 seconds and  gives-me the info below:
>
>
>
> ---
>
> ###################################################################### 
> ##########
> ##############
> Connection closed by remote host.
>
> ---
>
>
>
> if i connect the ftp again, and send a smaller file, it completes  
> all perfect.
>
>
>
> If i go and send the 6MB~ file again, but with the filezilla  
> windows client, when it gets the end, it stops also about around 30  
> seconds and after it finished.
>
>
>
> In the logs i don't see nothing that indicates error or something.
>
> How can i debug this more?

Is there anything such as a firewall or NAT/PAT device between the  
client and the server?    Could be something timing out there.

Could tcpdump and  look at both the data and the command channels on  
both client and server and compare what you see.

-Patrick

--
Patrick Muldoon
Network/Software Engineer
INOC (http://www.inoc.net)
PGPKEY (http://www.inoc.net/~doon)
Key ID: 0x370D752C

Printed on 100% recyclable phosphor.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
ProFTPD Users List   <proftpd-users <at> proftpd.org>
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
ProFTPD Users List   <proftpd-users <at> proftpd.org>
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html

[Proftpd-user] high cpu usage

Hi,

I'm running ProFTPD Version 1.3.1rc2 on gentoo host (Linux genovefa
2.6.21-gentoo-r4 #2 SMP Wed Jul 18 09:15:15 CEST 2007 i686 Intel(R)
Pentium(R) 4 CPU 3.00GHz GenuineIntel GNU/Linux). When remote host try
to access files from my ftp server CPU usage skyrockets to about 99%
and network performance is terribly low - about 3MB max on 100Mbit LAN
network.
My configuration is a simple anonymous ftp server (attached is the
config I use):

--->8---
# cat /etc/proftpd/proftpd.conf
# This is a basic ProFTPD configuration file (rename it to
# 'proftpd.conf' for actual use.  It establishes a single server
# and a single anonymous login.  It assumes that you have a user/group
# "nobody" and "ftp" for normal operation and anon.

ServerName          "ProFTPD Default Installation"
ServerType          standalone
DefaultServer       on
RequireValidShell   off
AuthPAM             off
AuthPAMConfig       ftp
# Port 21 is the standard FTP port.
Port				21

# Umask 022 is a good standard umask to prevent new dirs and files
# from being group and world writable.
Umask				022

# To prevent DoS attacks, set the maximum number of child processes
# to 30.  If you need to allow more than 30 concurrent connections
# at once, simply increase this value.  Note that this ONLY works
# in standalone mode, in inetd mode you should use an inetd server
# that allows you to limit maximum number of processes per service
# (such as xinetd).
MaxInstances			30

# Set the user and group under which the server will run.
User				proftpd
Group				proftpd

# Normally, we want files to be overwriteable.
<Directory />
  AllowOverwrite		on
</Directory>

# Append/restart enabled
AllowStoreRestart		on

# Vedno se prestavi v 'ta400' podmapo ce gre za uporabnika (ne velja
# za anonymous dostop).
## DefaultChdir			ta400

# A basic anonymous configuration, no upload directories.
<Anonymous ~ftp>
  User				ftp
  Group				ftp

  # We want clients to be able to login with "anonymous" as well as "ftp"
  UserAlias			anonymous ftp

  # Limit the maximum number of anonymous logins
  MaxClients			10

  # We want 'welcome.msg' displayed at login, and '.message' displayed
  # in each newly chdired directory.
  DisplayLogin			welcome.msg
#  DisplayFirstChdir		.message
  DisplayChdir		.message

  # Limit WRITE everywhere in the anonymous chroot
  <Limit WRITE>
    AllowAll
  </Limit>
  <Limit APPE>
    AllowAll
  </Limit>

</Anonymous>

--->8---

Is there anything wrong with the configuration?

Regards,
Hinko
--

-- 
HK

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
ProFTPD Users List   <proftpd-users <at> proftpd.org>
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html

Re: [Proftpd-user] Wierd Problem

On Oct 2, 2007, at 4:12 AM, Jorge Bastos wrote:

> Yes there's a NAT on the client side, but i belive it's not that,  
> in fact it
> can't.
> That happens with the 6MB~ file, but not with the 600Kb one.

An easy way to test is to try and upload the file from a different  
client on a different network and see if the problem reproduces it self.

If small files work and bigger files don't, I would look into  
something that might be timing out based on the increased duration of  
the transfer.  But if nothing stands out in the logs. Sniffing both  
side of the connection might shed more light on what exactly is  
happening.   But I would try uploading the same file from a different  
computer to rule on something b0rked on the client side.

-patrick

-- 
Patrick Muldoon
Network/Software Engineer
INOC (http://www.inoc.net)
PGPKEY (http://www.inoc.net/~doon)
Key ID: 0x370D752C

"Life's disappointments are harder to take when you don't know any  
swear words."
  --Calvin & Hobbes

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
ProFTPD Users List   <proftpd-users <at> proftpd.org>
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html

Re: [Proftpd-user] Wierd Problem

Doesn't work, already tryed with other ftp clients, command or with GUI,
with and without NAT.

-----Original Message-----
From: proftp-user-bounces <at> lists.sourceforge.net
[mailto:proftp-user-bounces <at> lists.sourceforge.net] On Behalf Of Patrick
Muldoon
Sent: terça-feira, 2 de Outubro de 2007 13:48
To: proftp-user <at> lists.sourceforge.net
Subject: Re: [Proftpd-user] Wierd Problem

On Oct 2, 2007, at 4:12 AM, Jorge Bastos wrote:

> Yes there's a NAT on the client side, but i belive it's not that,  
> in fact it
> can't.
> That happens with the 6MB~ file, but not with the 600Kb one.

An easy way to test is to try and upload the file from a different  
client on a different network and see if the problem reproduces it self.

If small files work and bigger files don't, I would look into  
something that might be timing out based on the increased duration of  
the transfer.  But if nothing stands out in the logs. Sniffing both  
side of the connection might shed more light on what exactly is  
happening.   But I would try uploading the same file from a different  
computer to rule on something b0rked on the client side.

-patrick

-- 
Patrick Muldoon
Network/Software Engineer
INOC (http://www.inoc.net)
PGPKEY (http://www.inoc.net/~doon)
Key ID: 0x370D752C

"Life's disappointments are harder to take when you don't know any  
swear words."
  --Calvin & Hobbes

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
ProFTPD Users List   <proftpd-users <at> proftpd.org>
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
ProFTPD Users List   <proftpd-users <at> proftpd.org>
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html

[Proftpd-user] Proftpd and RFC 2228

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

_______________________________________________
ProFTPD Users List   <proftpd-users <at> proftpd.org>
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html

Re: [Proftpd-user] Proftpd and RFC 2228

> I am using Proftpd 1.2.10 on a Linux machine.   The module, mod_tls, is
> deployed for security reason.   I am wondering if this configuration is
> compliance to RFC 2228.

The mod_tls module provides *one* implementation, using SSL/TLS, which
conforms to RFC2228.  The mod_gss module (available from SourceForge) is
another RFC2228 module for proftpd.

Hope this helps,
TJ

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   Read not to contradict and confute, nor to believe and take for granted, nor
   to find talk and discourse, but to weigh and consider.

   	-Francis Bacon

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
ProFTPD Users List   <proftpd-users <at> proftpd.org>
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html