🚀 go-pugleaf

Hello Simon,
I dont know the answer, but a couple of suggestions ...
You may have already tried this, but for problems which might be
permissions ,  then #  su - <user> , and try to do whatever is failing ,
ie in this case su - ftp , and try to create files in the
pub/incoming directory .
If ok then must be a ftpd (config) problem (?) rather than a file perms 
and vv .                                                            
If a ftp cfg problem then strace'ing  ftpd, and then firing the query 
at it might reveal the problem - and then again it might not :-).             
Hope you fix it soon,
Cheers,
Steve Houseman                            

-- 
                          
currently  steve.houseman at virgin net 

On Fri, 06 Aug 1999, Steve Houseman wrote:

>I dont know the answer, but a couple of suggestions ...
>You may have already tried this, but for problems which might be
>permissions ,  then #  su - <user> , and try to do whatever is failing ,
>ie in this case su - ftp , and try to create files in the
>pub/incoming directory .

Good suggestion. If I su - ftp then cd to pub/incoming I can create a file with
vi, so that suggests that permissions are OK?

>If ok then must be a ftpd (config) problem (?) rather than a file perms 
>and vv .                                                            
>If a ftp cfg problem then strace'ing  ftpd, and then firing the query 
>at it might reveal the problem - and then again it might not :-).             

If I edit inetd.conf to change the ftp line to 

/usr/sbin/tcpd  /usr/bin/strace -o /home/simon/stracelog in.ftpd -l -a

then logging does start, but unfortunately it seems to make all logins fail,
whether user or anonymous, so I don't get as far as attempting an upload :-(
   
[root@tower /root]# ftp localhost
Connected to localhost.
220 tower.localdomain FTP server (Version wu-2.5.0(1) Tue Jun 8 08:55:12 EDT 1999) ready.
Name (localhost:root): simon
331 Password required for simon.
Password:
ptrace: umoven: Input/output error
ftp> quit
ptrace: umoven: Input/output error       
Login failed.         

Try again:

[root@tower /root]# ftp localhost
Connected to localhost.
220 tower.localdomain FTP server (Version wu-2.5.0(1) Tue Jun 8 08:55:12 EDT 1999) ready.
Name (localhost:root): ftp
331 Guest login ok, send your complete e-mail address as password.
Password:
ptrace: umoven: Input/output error
Login failed.
ftp> quit
ptrace: umoven: Input/output error
[root@tower /root]#                     

This produces several hundred lines in stracelog, so I won't post it here :-)

Any more suggestions??
  
-- 
Simon Child

Simon Child <simon@child.demon.co.uk>  wrote ....
> Good suggestion. If I su - ftp then cd to pub/incoming I can create 
> a file with vi, so that suggests that permissions are OK?

yup - perms must be ok (famous last words :-) ).                            

Had not tried to strace an inet daemon before - fun eh? 

Obviously some things are different on your system from mine, 
as tracing did not work at all with the format you had in inetd.conf.
I was on the verge of giving up on this but I found that eliminating
the tcpd (takes no part after initial check) and putting the strace in
a script allowed a trace to happen ....eg 

ls -ald /usr/local/bin/ftpdtrace    
-rwxr-xr-x   1 root     root           83 Aug  7 00:24 /usr/local/bin/ftpdtrace

cat  /usr/local/bin/ftpdtrace    
#!/bin/bash
/usr/bin/strace -o/tmp/dbin  /usr/sbin/wu.ftpd  -l -a    

I dont have in.ftpd only wu.ftpd (no idea what difference is)
(Worth just checking that this runs manually ie /usr/local/bin/ftpdtrace ,
- trace should exist and show a failure due to not a socket.)                 

/etc/inetd/conf has a line now like .....
ftp     stream  tcp     nowait  root    /usr/local/bin/ftpdtrace   
 
This format seemed to work ie ran as normal and got a trace out, 
though may not work on yours ?.
 
Hope this works on yours AND that something useful comes of it :-)
                            
Cheers,
Steve Houseman

-- 
                          
currently  steve.houseman at virgin net 

Steve Houseman <steve@rockhopper.woolacombe.lnx> doodled in uk.comp.os.linux:

> cat  /usr/local/bin/ftpdtrace    
> #!/bin/bash
> /usr/bin/strace -o/tmp/dbin  /usr/sbin/wu.ftpd  -l -a    

Yikes, didn't anything interesting turn up in /var/log/messages, security or
the xferlog before resorting to strace?

> I dont have in.ftpd only wu.ftpd (no idea what difference is)

Ah. wu.ftpd is a decent & more-configureable thing than in.ftpd, although for
some strange reason, I'm running proftpd here.

Check your /etc/ftpaccess file. The chances are at least one of the
directories isn't set to allow incoming (writes) from anonymous users.

-- 
~Tim
 ___ http://www.glutinous.custard.org/ _______ tim@glutinous.custard.org ____
| Geek Code: GCS dpu s-:+ a-- C++++ UBLUAVHSC++++ P+++ L++ E--- W+++(--) N++ |
| w--- O- M-- V-- PS PGP++ t--- X+(-) b D+ G e++(*) h++(*) r--- y-	     |
|  .|` Clouds cross the black moonlight /				     |
|      Rushing on down to the circle of the turning world .|`	(Runrig)     |
`----------------------------------------------------------------------------'

piglet@glutinous.custard.org (Tim Haynes) wrote ....      
> <snip>                  
> Yikes, didn't anything interesting turn up in /var/log/messages, 
> security or the xferlog before resorting to strace?
><snip>        

just responding to that point ...if I try something and it fails then 
if I knew where it dumped its error messages then I would look there.
If I didnt know that or they werent helpful then I would normally
try to  run strace on it.
*If* the strace runs ok then it is quick   .... and is
good at providing indicators for  problems like 
- what PATH it is using to find a lib,
- what file access is failing  
- what host is being queried ....   
- and probably others  that I cant think of at this moment. 

It is of little (zero?) use if the problem is due to configuration
problems such that a request is made and immediately denied without
any intervening system call action eg files being consulted. 

It does not work for suid progs (man says it turns of suid) and
I certainly have had problems running it in some situations -
normally the most interesting (read important) .

So strace can be a *quick* solution to tracking down a problem 
or of little help ... if it aint quick , I wouldnt persist with
it , but move on to some other debugging method (RTFM , source or NG?).
So in the original posting problem, I would normally have given
up trying to get strace to work , but as I had recommended it,
I felt that I ought to try a little harder before giving up :-)

It may well be that strace is not the best tool for this problem.

Cheers,
Steve Houseman 

-- 
                          
currently  steve.houseman at virgin net 

Steve Houseman <steve@rockhopper.woolacombe.lnx> doodled in uk.comp.os.linux:
> > <snip>                  
> > Yikes, didn't anything interesting turn up in /var/log/messages, security
> > or the xferlog before resorting to strace?
> ><snip>        
> 
> just responding to that point ...if I try something and it fails then if I
> knew where it dumped its error messages then I would look there.  If I didnt
> know that or they werent helpful then I would normally try to run strace on
> it.

The point is not that I'm wondering whether you've jumped straight into a
potentially-messy way of debugging something (after all, I resort to strace
and equivalents like truss on a not-rarely basis, but more for sending core-
dump cases to developers than debugging ftpd setups), but rather that I'm
tentatively suggesting a few locations where you /might/ see something useful.

-- 
~Tim
 ___ http://www.glutinous.custard.org/ _______ tim@glutinous.custard.org ____
| Geek Code: GCS dpu s-:+ a-- C++++ UBLUAVHSC++++ P+++ L++ E--- W+++(--) N++ |
| w--- O- M-- V-- PS PGP++ t--- X+(-) b D+ G e++(*) h++(*) r--- y-	     |
|  .|` Clouds cross the black moonlight /				     |
|      Rushing on down to the circle of the turning world .|`	(Runrig)     |
`----------------------------------------------------------------------------'

On Sun, 08 Aug 1999, Tim Haynes wrote:

>Yikes, didn't anything interesting turn up in /var/log/messages, security or
>the xferlog before resorting to strace?

Afraid not. Nothing helpful in messages (records an anonymous login and the
subsequent closing of the ftp session). /var/log/secure records a connect from
localhost. xferlog records downloads, but gives no record of refusal of uploads.

>Check your /etc/ftpaccess file. The chances are at least one of the
>directories isn't set to allow incoming (writes) from anonymous users.

I posted my ftpaccess file at the beginning of this thread. It is as installed
by the RH6.0 install, and with a couple of changes that I tried indicated by
comments.

I've tried this in three machines now, all the same result. Two are fresh
installs of RH6.0, and one is an upgrade from RH5.2 on which anon ftp upload
was working previously. Either I'm doing something very silly or there is a bug
in RH60 somewhere? Has anyone got anon ftp uploading working on RH6.0?

RH6.0 is using shadow passwords, which I wasn't using on 5.2 - is that anything
to do with it? But authentication seems alright (I'm allowed an anonymous
connect and can download files) and permissions seem alright (user ftp can
write files to the incoming directory).

I'll go and play with strace now unless someone has a better idea...

-- 
Simon Child

On Sat, 07 Aug 1999, Steve Houseman wrote:

>Had not tried to strace an inet daemon before - fun eh? 

Never heard of strace before <g>.

>This format seemed to work ie ran as normal and got a trace out, 
>though may not work on yours ?.

Didn't work for me - I got the same as I said before. However the man page gave
me an idea, and it worked.

Open two consoles, in one run top and in the other ftp localhost. Spot the pid
of in.ftpd and do

strace -p[pid of in.ftpd] -o/tmp/tracelog

I got error messages similar to before but a log was recorded and I was able to
log in, cd /pub/incoming, download a file, and then attempt an upload of a file
called dbin. Same error message as before, and the (apparently) relevant part of
the log from strace showed as below. Does it make any sense to you? 

time(NULL)                              = 934141318
stat("/etc/shutmsg", 0xbfffdfcc)        = -1 ENOENT (No such file or directory)
read(0, "STOR dbin\r\n", 1024)          = 11
alarm(0)                                = 900
time(NULL)                              = 934141318
open(".", O_RDONLY)                     = 6
lstat("dbin", 0xbfff95ac)               = -1 ENOENT (No such file or directory)
connect(-1073764696, {...}, 1075031232) = 14
fchdir(6)                               = 0
close(6)                                = 0
stat("dbin", 0xbfffb664)                = -1 ENOENT (No such file or directory)
open(".", O_RDONLY)                     = 6
lstat(".", {st_mode=0, st_size=0, ...}) = 0
chdir(".")                              = 0
connect(-1073764704, {...}, 1075031232) = 14
fchdir(6)                               = 0
close(6)                                = 0
open(".", O_RDONLY)                     = 6
chdir("/")                              = 0
connect(-1073782292, {...}, 1075031232) = 2
fchdir(6)                               = 0
close(6)                                = 0
open(".", O_RDONLY)                     = 6
chdir("/")                              = 0
connect(-1073772896, {...}, 1075031232) = 2
fchdir(6)                               = 0
close(6)                                = 0
write(1, "553 dbin: Permission denied on s"..., 49) = 49
SYS_174(0xe, 0xbfffe6bc, 0xbfffe630, 0x8, 0xe) = 0
alarm(900)                              = 0
time([934141318])                       = 934141318
time(NULL)                              = 934141318
stat("/etc/shutmsg", 0xbfffdfcc)        = -1 ENOENT (No such file or directory) 

This is on a fresh install of RH6.0 with errata upgrades applied:

[root@compaq /tmp]# uname -r
2.2.5-22
[root@compaq /tmp]# rpm -qf /usr/sbin/in.ftpd
wu-ftpd-2.5.0-2
[root@compaq /tmp]#        

-- 
Simon Child

In article <934138800.381262543@192.168.1.1>, Simon Child wrote:
>On Sun, 08 Aug 1999, Tim Haynes wrote:
>
>>Yikes, didn't anything interesting turn up in /var/log/messages, security or
>>the xferlog before resorting to strace?
>
>Afraid not. Nothing helpful in messages (records an anonymous login and the
>subsequent closing of the ftp session). /var/log/secure records a connect from
>localhost. xferlog records downloads, but gives no record of refusal of uploads.
>
>>Check your /etc/ftpaccess file. The chances are at least one of the
>>directories isn't set to allow incoming (writes) from anonymous users.
>
>I posted my ftpaccess file at the beginning of this thread. It is as installed
>by the RH6.0 install, and with a couple of changes that I tried indicated by
>comments.
>
>I've tried this in three machines now, all the same result. Two are fresh
>installs of RH6.0, and one is an upgrade from RH5.2 on which anon ftp upload
>was working previously. Either I'm doing something very silly or there is a bug
>in RH60 somewhere? Has anyone got anon ftp uploading working on RH6.0?
>
>RH6.0 is using shadow passwords, which I wasn't using on 5.2 - is that anything

If you're using shadow passwords you might want to read the documentation
for wu-ftpd. You always wanted to do that anyway but now it's about time.
Grab the source and using the debug switch is usually helpful too.

>to do with it? But authentication seems alright (I'm allowed an anonymous
>connect and can download files) and permissions seem alright (user ftp can
>write files to the incoming directory).
anonymous does not have a password and user ftp usually has none either or
to be more specific, the password entry ought to be just a !.

Ta',
Juergen

-- 
\ Real name     : J�rgen Heinzl                 \       no flames      /
 \ EMail Private : juergen@monocerus.demon.co.uk \ send money instead /

Simon Child <simon@child.demon.co.uk> doodled in uk.comp.os.linux:
> >Yikes, didn't anything interesting turn up in /var/log/messages, security or
> >the xferlog before resorting to strace?
> Afraid not. Nothing helpful in messages (records an anonymous login and the
> subsequent closing of the ftp session). /var/log/secure records a connect
> from localhost. xferlog records downloads, but gives no record of refusal of
> uploads.

Pants! :(  :)

> >Check your /etc/ftpaccess file. The chances are at least one of the
> >directories isn't set to allow incoming (writes) from anonymous users.
> I posted my ftpaccess file at the beginning of this thread. It is as
> installed by the RH6.0 install, and with a couple of changes that I tried
> indicated by comments.

Ah. Can you remind me then, what did it have for the section:

	#specify the upload directory information
	upload  /home/ftp  *             no
	upload  /home/ftp  /incoming     yes     root    daemon  0600 dirs
	upload  /home/ftp  /bin          no
	upload  /home/ftp  /etc          no

A slackware box I use has this, and with suitable permissions on
~ftp/incoming/ (bearing in mind that you're writing into the directory as the
'ftp' user) it works fine.

> RH6.0 is using shadow passwords, which I wasn't using on 5.2 - is that
> anything to do with it? But authentication seems alright (I'm allowed an
> anonymous connect and can download files) and permissions seem alright (user
> ftp can write files to the incoming directory).

Shadow password auth shouldn't have any effect on it at all, if you're coming
in as anonymous.

-- 
~Tim
 ___ http://www.glutinous.custard.org/ _______ tim@glutinous.custard.org ____
| Geek Code: GCS dpu s-:+ a-- C++++ UBLUAVHSC++++ P+++ L++ E--- W+++(--) N++ |
| w--- O- M-- V-- PS PGP++ t--- X+(-) b D+ G e++(*) h++(*) r--- y-	     |
|  .|` Clouds cross the black moonlight /				     |
|      Rushing on down to the circle of the turning world .|`	(Runrig)     |
`----------------------------------------------------------------------------'

Simon Child <simon@child.demon.co.uk> wrote ......... 
<snip>              
> Didn't work for me - I got the same as I said before. However 
> the man page gave me an idea, and it worked.

> Open two consoles, in one run top and in the other ftp localhost. 
> Spot the pid of in.ftpd and do

> strace -p[pid of in.ftpd] -o/tmp/tracelog

> I got error messages similar to before but a log was recorded and 
> I was able to log in, cd /pub/incoming, download a file, and 
> then attempt an upload of a file called dbin. Same error message 
> as before, and the (apparently) relevant part of the log from 
> strace showed as below. Does it make any sense to you? 
<snip>              

Congratulations on getting  a trace  :-)     
.. unfortunately I couldnt  make anything positive of it  :-( 

.. the connect statements eg ...
connect(-1073764696, {...}, 1075031232) = 14
dont match man pages or any doc I have for it .. first arg is an fd 
and return val - 0 is ok and -1 , with errno set if error , and neither
seem good... so maybe indicates mismatch between strace and the 
library (or my docs)...             
Also dont know what it is attempting to connect to ... but probably  
doesnt matter for this problem .            

However, I would have expected to see some access to the dir 
with either a write failure or a stat on the dir ... there is 
only one such ...
> lstat(".", {st_mode=0, st_size=0, ...}) = 0


spent some time cogitating (read- scratching my head) and couldnt
make anything of this except that probably the stat on the dir
seemed to be the only possible cause ....
Anyway tried your strace technique on my system and works fine 
and can see it stat'ing the dirs ... found I had the same symptom. 
After muchos b*ggering around it seems that the problem is the 
ftpaccess line ..                 
upload  /home/ftp  *             no
if change that to                       
upload  /home/ftp   /             no
and rely on the 
upload  /home/ftp   /bin          no
upload  /home/ftp   /etc          no
to stop unwanted uploads there, then it does upload into the 
pub/incoming dir ....                       

Hope that fixes it,
Cheers,
Steve Houseman 

-- 
                          
currently  steve.houseman at virgin net 

On Mon, 9 Aug 1999 10:49:37 +0100, Simon Child
<simon@child.demon.co.uk> wrote:

>Has anyone actually got anon ftp upload to work on RH6.0, or is it time for a
>bug report to RedHat??

Im still very new to Linux and hadn't even looked much at ftp until
this thread but for what its worth this works for me and still stops
uploading to anything other than incoming.

Hope its of some help

Simon.

/etc/ftpaccess
class   all   real,guest,anonymous  *

email root@localhost

loginfails 5

readme  README*    login
readme  README*    cwd=*

message /welcome.msg            login
message .message                cwd=*

compress        yes             all
tar             yes             all
chmod		no		guest,anonymous
delete		no		guest,anonymous
overwrite	no		guest,anonymous
rename		no		guest,anonymous

upload /home/ftp /incoming yes ftp daemon 0666


log transfers anonymous,real inbound,outbound

shutdown /etc/shutmsg

passwd-check rfc822 warn

On Sun, 08 Aug 1999, Tim Haynes wrote:

>Ah. Can you remind me then, what did it have for the section:
>
>	#specify the upload directory information
>	upload  /home/ftp  *             no
>	upload  /home/ftp  /incoming     yes     root    daemon  0600 dirs
>	upload  /home/ftp  /bin          no
>	upload  /home/ftp  /etc          no


/etc/ftpaccess

class   all   real,guest,anonymous  *

email root@localhost

loginfails 5

readme  README*    login
readme  README*    cwd=*

message /welcome.msg            login
message .message                cwd=*

compress        yes             all
tar             yes             all
chmod           no              guest,anonymous
delete          no              guest,anonymous
overwrite       no              guest,anonymous
rename          no              guest,anonymous

log transfers anonymous,real inbound,outbound

shutdown /etc/shutmsg

passwd-check rfc822 warn

#I've tried adding these lines from the man page:

upload  /home/ftp  *               no
upload  /home/ftp  /pub/incoming       yes  ftp   daemon 0666

#and also tried:

anonymous-root /home/ftp

-- 
Simon Child

On Sun, 08 Aug 1999, Steve Houseman wrote:

>After muchos b*ggering around it seems that the problem is the 
>ftpaccess line ..                 
>upload  /home/ftp  *             no
>if change that to                       
>upload  /home/ftp   /             no
>and rely on the 
>upload  /home/ftp   /bin          no
>upload  /home/ftp   /etc          no
>to stop unwanted uploads there, then it does upload into the 
>pub/incoming dir ....                       

It sounded promising... but no better.

Even if I comment out the line 

upload  /home/ftp  *             no

I still can't upload.

Has anyone actually got anon ftp upload to work on RH6.0, or is it time for a
bug report to RedHat??

-- 
Simon Child

On Tue, 10 Aug 1999, Simon Kelsall wrote:

>Im still very new to Linux and hadn't even looked much at ftp until
>this thread but for what its worth this works for me and still stops
>uploading to anything other than incoming.

This is weird. It's only different from my original in that it
doesn't specifically block uploads to anywhere other than incoming (and
as you say you can't upload anywhere else anyway), but it works for me,
and indeed my old ftpaccess with those other lines works for me now
as well!!

So I've gone through line by line commenting out and putting
back. One of the lines that I put in when trying to fix it was

anonymous-root /home/ftp   

If I comment this out then it all works alright. It must have been
broken for some other reason when I put this in, and then I forgot to
take this out afterwards. But from my reading of the man page this line
is valid, so I'm not sure why it breaks it. 

Ho hum.

Thanks to all of you.

-- 
Simon Child