Bugs item #1790403, was opened at 2007-09-07 12:24
Message generated for change (Comment added) made by dfandrich
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1790403&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: TFTP
Group: wrong behaviour
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: darpin (darpin1963)
Assigned to: Daniel Stenberg (bagder)
Summary: Permission Denied TFTP upload reports success

Initial Comment:
The Problem:
Performing a TFTP upload to a file without sufficient write permissions on the destination file results in an unreported failure.

Witnessed on:
Fedora Core 6
[root_at_dpiner01 ~]# uname -a
Linux dpiner01 2.6.22.2-42.fc6 #1 SMP Wed Aug 15 12:34:26 EDT 2007 i686 i686 i386 GNU/Linux

[root_at_dpiner01 ~]# curl -V
curl 7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
Protocols: tftp ftp telnet dict ldap http file https ftps
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz

I also tried against curl-7.16.4.tar.gz configured with:
./configure --without-ssl --disable-shared --enable-debug

Programmatic usage (i.e., libcurl) compiled/linked with:
[root_at_dpiner01 ~]# g++ -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=i386-redhat-linux
Thread model: posix
gcc version 4.1.2 20070626 (Red Hat 4.1.2-13)

Recreating the problem on the command-line:
Create a file in the TFTP's directory (e.g., /tftpboot/junk.dat.)
   cd /tftpboot
   touch junk.dat
   ll junk.dat
[root_at_dpiner01 ~]# ll junk.dat
-rw-r--r-- 1 root root 0 Sep 7 10:43 junk.dat

Create and populate a file named /tmp/junk.dat.
   cat -> /tmp/junk.dat
   This is a junk file.
   ^D
   ll /tmp/junk.dat
[root_at_dpiner01 ~]# ll /tmp/junk.dat
-rw-r--r-- 1 root root 21 Sep 7 10:47 /tmp/junk.dat

In the /tmp directory, issue the following command:
   curl --verbose --upload-file junk.dat tftp://10.191.2.108/junk.dat

[root@dpiner01 tmp]# curl --verbose --upload-file junk.dat tftp://10.191.2.108/junk.dat
* About to connect() to 10.191.2.108 port 69
* Trying 10.191.2.108... connected
* Connected to 10.191.2.108 (10.191.2.108) port 69
* set timeouts for state 0; Total 30, retry 5 maxtry 6
* Permission denied
  % Total % Received % Xferd Average Speed Time Time Time Current
                                 Dload Upload Total Spent Left Speed
  0 21 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Closing connection #0

Examine the tftpboot directory:
   ll junk.dat
[root_at_dpiner01 tftpboot]# ll junk.dat
-rw-r--r-- 1 root root 0 Sep 7 10:43 junk.dat

(note the file size remains zero.)

Make it work:
   chmod 777 /tftpboot/junk.dat
[root_at_dpiner01 tftpboot]# ll junk.dat
-rwxrwxrwx 1 root root 0 Sep 7 10:43 junk.dat

Issue same curl command:
[root@dpiner01 tmp]# curl --verbose --upload-file junk.dat tftp://10.191.2.108/junk.dat
* About to connect() to 10.191.2.108 port 69
* Trying 10.191.2.108... connected
* Connected to 10.191.2.108 (10.191.2.108) port 69
* set timeouts for state 0; Total 30, retry 5 maxtry 6
  % Total % Received % Xferd Average Speed Time Time Time Current
                                 Dload Upload Total Spent Left Speed
  0 21 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected for transmit
* set timeouts for state 2; Total 3600, retry 15 maxtry 24
  0 21 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Closing connection #0

Examine the tftpboot directory:
[root_at_dpiner01 tftpboot]# ll junk.dat
-rwxrwxrwx 1 root root 21 Sep 7 10:54 junk.dat

(note the correct file size indicate the upload completed successfully.)

What happens in failure scenario:
   rm /tftpboot/junk.dat
   ll /tftpboot/junk.dat
[root_at_dpiner01 tftpboot]# ll /tftpboot/junk.dat
ls: /tftpboot/junk.dat: No such file or directory

Issue the same curl command:
   curl --verbose --upload-file junk.dat tftp://10.191.2.108/junk.dat

[root@dpiner01 tmp]# curl --verbose --upload-file junk.dat tftp://10.191.2.108/junk.dat
* About to connect() to 10.191.2.108 port 69
* Trying 10.191.2.108... connected
* Connected to 10.191.2.108 (10.191.2.108) port 69
* set timeouts for state 0; Total 30, retry 5 maxtry 6
* File not found
  % Total % Received % Xferd Average Speed Time Time Time Current
                                 Dload Upload Total Spent Left Speed
  0 21 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Closing connection #0
* TFTP: File Not Found

curl: (68) TFTP: File Not Found

Programmatically,the following snippet:

            string srcFile = "junk.dat";
            string url = "tftp://10.191.2.108/junk.dat";
            char errorBuffer[ 1024 ] = { 0, };

            CURL* handle = curl_easy_init();
            
            struct stat statusBuffer = { 0, };
            off_t fileSize = 0;
            stat( srcFile.c_str(), &statusBuffer );
            fileSize = statusBuffer.st_size;
            
            curl_easy_setopt( handle, CURLOPT_VERBOSE, true );
            curl_easy_setopt( handle, CURLOPT_URL, url.c_str() );
            curl_easy_setopt( handle, CURLOPT_READDATA, file );
            curl_easy_setopt( handle, CURLOPT_INFILESIZE, fileSize );
            curl_easy_setopt( handle, CURLOPT_UPLOAD, true );
            curl_easy_setopt( handle, CURLOPT_FAILONERROR, !0 );
            curl_easy_setopt( handle, CURLOPT_ERRORBUFFER, errorBuffer );
            curl_easy_setopt( handle, CURLOPT_TRANSFERTEXT, 0 );

            CURLcode result = curl_easy_perform( handle );
            if ( CURLE_OK == result )
            {
               printf( "OK\n" );
            }
            else
            {
               printf( "Bad - error: '%s'\n", outErrorBuffer );
            }
            curl_easy_cleanup( handle );

 In the permission denied scenario, curl_easy_perform reports CURLE_OK (i.e., OK is printf'd.)

Seems like CURLE_TFTP_PERM would be an appropriate return value.
curl.h: CURLE_TFTP_PERM, /* 69 - permission problem on server */

But then looking at the tftp utility's output in the failed scenario shows:

[root_at_dpiner01 tmp]# tftp -v 10.191.2.108
Connected to 10.191.2.108 (10.191.2.108), port 69
tftp> trace
Packet tracing on.
tftp> put junk.dat
putting junk.dat to 10.191.2.108:junk.dat [netascii]
sent WRQ <file=junk.dat, mode=netascii>
received ERROR <code=0, msg=Permission denied>
Error code 0: Permission denied

That is, the Permission denied error code = 0. Yikes! Which is troubling because the error checking logic in tftp.c assumes zero is the non-error case.

FWIW, the tftp software's version is:
[root_at_dpiner01 tmp]# rpm -qa | grep tftp
tftp-server-0.42-3.1
tftp-0.42-3.1

Would someone comment on this behavior? Is it a problem with cUrl (which in itself is wicked cool by the way?) Or, perhaps a problem with the tftp client or server?

Thank you.

++darrell

----------------------------------------------------------------------

>Comment By: Dan Fandrich (dfandrich)
Date: 2007-09-07 13:36

Message:
Logged In: YES
user_id=236775
Originator: NO

Ah, that trace you provided shows that it's a server problem--it should be
returning code=2, not code=0. But curl should really be treating code=0 as
an error, too. I've just checked in a change to do so.

----------------------------------------------------------------------

Comment By: Dan Fandrich (dfandrich)
Date: 2007-09-07 13:07

Message:
Logged In: YES
user_id=236775
Originator: NO

I've just added test case 1007 to CVS to test this kind of scenario, and
curl returns error 69 as you would expect. Can you try tomorrow's daily
snapshot or CVS and see if you're still getting that problem?

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1790403&group_id=976
Received on 2007-09-07