Bug 39467 - creating directories via ftp results in root.root ownership
creating directories via ftp results in root.root ownership
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: wu-ftpd (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bernhard Rosenkraenzer
David Lawrence
Directories created owned by root
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-05-07 16:40 EDT by Stephen Samuel
Modified: 2007-04-18 12:33 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-12-02 11:21:57 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
tar of ftp config files (20.00 KB, application/octet-stream)
2001-05-08 17:50 EDT, Stephen Samuel
no flags Details
patch against wu-ftpd-2.6.1-16 (1.89 KB, patch)
2001-07-02 10:28 EDT, Michael Schwendt
no flags Details | Diff

  None (edit)
Description Stephen Samuel 2001-05-07 16:40:59 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.2.17-14 i686)

Description of problem:
Directories created via the mkdir command in ftp are owned by root.
Files PUT via ftp are owned by the proper user.

How reproducible:
Always

Steps to Reproduce:
1. ftp localhost (login)
2. mkdir somedir
3. put somefile somefile2
4. ls
	

Actual Results:  somefile is owned by me
somedir is owned by root.root

Expected Results:  somefile is owned by me
somedir is owned by me.

Additional info:

[jbeima@gateway jbeima]$ ftp localhost
Connected to localhost.
220 gateway.xxxxxxx FTP server (Version wu-2.6.1-16) ready.
Name (localhost:jbeima): jbeima
331 Password required for jbeima.
Password:
230-Welcome To xxxxxx's FTP Server!
230-Authorized Users ONLY!
230-
230 User jbeima logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls 
227 Entering Passive Mode (127,0,0,1,183,11)
150 Opening ASCII mode data connection for directory listing.
total 24
drwxr-xr-x   2 500      500          4096 Apr 28 06:46 Desktop
-rw-rw----   1 500      500           224 May  6 13:39 bprof
drwxrwx---   2 root     root         4096 May  6 13:39 junk
226 Transfer complete.
ftp> mkdir junk2
257 "/home/jbeima/junk2" new directory created.
ftp> ls
227 Entering Passive Mode (127,0,0,1,204,132)
150 Opening ASCII mode data connection for directory listing.
total 32
drwxr-xr-x   2 500      500          4096 Apr 28 06:46 Desktop
-rw-rw----   1 500      500           224 May  6 13:39 bprof
drwxrwx---   2 root     root         4096 May  6 13:39 junk
drwxrwx---   2 root     root         4096 May  7 14:30 junk2
226 Transfer complete.
ftp> put bprof bprof2
local: bprof remote: bprof2
227 Entering Passive Mode (127,0,0,1,13,111)
150 Opening BINARY mode data connection for bprof2.
226 Transfer complete.
224 bytes sent in 0.0396 secs (5.5 Kbytes/sec)
ftp> ls
227 Entering Passive Mode (127,0,0,1,215,52)
150 Opening ASCII mode data connection for directory listing.
total 40
drwxr-xr-x   2 500      500          4096 Apr 28 06:46 Desktop
-rw-rw----   1 500      500           224 May  6 13:39 bprof
-rw-rw----   1 500      500           224 May  7 14:31 bprof2
drwxrwx---   2 root     root         4096 May  6 13:39 junk
drwxrwx---   2 root     root         4096 May  7 14:30 junk2
226 Transfer complete.
ftp> mkdir junk2/subdir
550 junk2/subdir: Permission denied.
ftp> put bprof junk2/subfile
local: bprof remote: junk2/subfile
227 Entering Passive Mode (127,0,0,1,171,68)
553 junk2/subfile: Permission denied.
ftp> quit
221-You have transferred 224 bytes in 1 files.
221-Total traffic for this session was 1368 bytes in 1 transfers.
Comment 1 Bernhard Rosenkraenzer 2001-05-08 08:00:00 EDT
Doesn't happen here. However, you can configure wu-ftpd to do this by using 
upload lines in /etc/ftpaccess, which is probably what you have done.
Comment 2 Stephen Samuel 2001-05-08 17:50:27 EDT
Created attachment 17786 [details]
tar of ftp config files
Comment 3 Stephen Samuel 2001-05-08 17:57:58 EDT
The only upload line I can find in the ftpaccess file is: 

upload	/home/*	*	yes	*	*	0660	dirs

According to this, files should be owned according to the ownership of
the parent directory.  Directories (because the dir owner/group is missing)
should do the same.

From the man page:
            The optional  parameters  <dirowner>  and  <dirgroup>
            specify the ownership of the new directory.  If omit-
            ted, the <owner> and <group> parameters are  used  as
            above.   If specified as "*" the directory is created
            with the ownership of the parent directory.

I'm attatching a tar of our config files... See if this helps the \reproduction
of the bug.

(It APPEARS that the parser may be taking a missing dir owner and group to mean
that the owner and group should be zero (root).
  (their is no space after the 'dirs' keyword)

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

This session log shows the ownership of the parent directory...


ftp localhost
Connected to localhost.
220 gateway.zenocopy.com FTP server (Version wu-2.6.1-16) ready.
Name (localhost:jbeima): jbeima
331 Password required for jbeima.
Password:
230-Welcome To Zenocopy's FTP Server!
230-Authorized Users ONLY!
230-
230 User jbeima logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls -a
227 Entering Passive Mode (127,0,0,1,29,237)
150 Opening ASCII mode data connection for directory listing.
total 120
drwxrwx---   7 500      500          4096 May  8 15:28 .
drwxr-xr-x  22 root     root         4096 Apr 28 13:13 ..
-rw-------   1 500      500           500 May  8 15:28 .bash_history
-rw-r--r--   1 500      500            24 Apr 28 06:46 .bash_logout
-rw-r--r--   1 500      500           224 Apr 28 06:46 .bash_profile
-rw-r--r--   1 500      500           124 Apr 28 06:46 .bashrc
-rw-r--r--   1 500      500           747 Apr 28 06:46 .emacs
drwxr-xr-x   3 500      500          4096 Apr 28 06:46 .kde
-rw-r--r--   1 500      500          3728 Apr 28 06:46 .screenrc
drwx------   3 500      500          4096 Apr 28 16:37 .xauth
drwxr-xr-x   2 500      500          4096 Apr 28 06:46 Desktop
-rw-rw----   1 500      500           224 May  6 13:39 bprof
-rw-rw----   1 500      500           224 May  7 14:31 bprof2
drwxrwx---   2 root     root         4096 May  6 13:39 junk
drwxrwx---   2 root     root         4096 May  7 14:30 junk2
226 Transfer complete.
ftp> put bprof2 bprof3
local: bprof2 remote: bprof3
227 Entering Passive Mode (127,0,0,1,144,29)
150 Opening BINARY mode data connection for bprof3.
226 Transfer complete.
224 bytes sent in 0.000182 secs (1.2e+03 Kbytes/sec)
ftp> mkdir junk3
257 "/home/jbeima/junk3" new directory created.
ftp> ls -la
227 Entering Passive Mode (127,0,0,1,93,200)
150 Opening ASCII mode data connection for directory listing.
total 136
drwxrwx---   8 500      500          4096 May  8 15:32 .
drwxr-xr-x  22 root     root         4096 Apr 28 13:13 ..
-rw-------   1 500      500       500 May  8 15:28 .bash_history
-rw-r--r--   1 500      500            24 Apr 28 06:46 .bash_logout
-rw-r--r--   1 500      500           224 Apr 28 06:46 .bash_profile
-rw-r--r--   1 500      500           124 Apr 28 06:46 .bashrc
-rw-r--r--   1 500      500           747 Apr 28 06:46 .emacs
drwxr-xr-x   3 500      500          4096 Apr 28 06:46 .kde
-rw-r--r--   1 500      500          3728 Apr 28 06:46 .screenrc
drwx------   3 500      500          4096 Apr 28 16:37 .xauth
drwxr-xr-x   2 500      500          4096 Apr 28 06:46 Desktop
-rw-rw----   1 500      500           224 May  6 13:39 bprof
-rw-rw----   1 500      500           224 May  7 14:31 bprof2
-rw-rw----   1 500      500           224 May  8 15:31 bprof3
drwxrwx---   2 root     root         4096 May  6 13:39 junk
drwxrwx---   2 root     root         4096 May  7 14:30 junk2
drwxrwx---   2 root     root         4096 May  8 15:32 junk3
226 Transfer complete.
ftp> 

Comment 4 Stephen Samuel 2001-05-08 18:03:58 EDT
I have verified that appending (the supposedly optional) '0660 * *' produces 
the proper result.

This DOES appear to be a parser bug.

Old line:
upload	/home/*	*	yes	*	*	0660	dirs

New line:
upload	/home/*	*	yes	*	*	0660	dirs 0660 * * 
Comment 5 Michael Schwendt 2001-07-01 22:13:43 EDT
Can confirm this here. From the man page:

    The  <owner>  and/or <group> may each be specified as "*", in which case any
uploaded files or  directories will  be  created with the ownership of the
directory in which they are created.

    The optional  parameters  <dirowner>  and  <dirgroup> specify the ownership
of the new directory.  If omit-ted, the <owner> and <group> parameters are  used
 as above.   If specified as "*" the directory is created with the ownership of
the parent directory.

----

If <dirowner> <dirgroup> are omitted and <owner> <group> is * *, newly created
directories in top-level incoming are 4095.root as opposed to ftp.ftp (which is
owner.group if my incoming). Where does the 4095 come from? Don't have such uid.

If I append * * for <dirowner> <dirgroup>, I get correct ownership 14.50 (ftp.ftp).
Comment 6 Stephen Samuel 2001-07-01 23:16:36 EDT
From this, my GUESS (not looking at the source) is that, unless the * * is
esplicitly there, the default is to use the specified uid/group. Unfortunately,
they aren't specified, so uninitialized variable values are used instead. 

Given that the values of uninitialized variables (esp. automatic ones) are
undefined in C, the uid/gid will be semi-random (dependent on compiler, OS,
phase of the moon, etc).  We just happened  to get 0/0 and you got 4095/0

My test:
-----------------------------------------------------
[samuel@me /tmp]$ cat tst.c
main(){
a();   b();
};

a(){
char x[200];
int i;
for(i=0;i<200;x[i++]=i);
};

b(){
int a,b,c,d;
printf("values: %x  %x %x %x\n",a,b,c,d);
};
[samuel@me /tmp]$ make tst
cc     tst.c   -o tst
[samuel@me /tmp]$ ./tst
values: c7c6c5c4  c3c2c1c0 bfbebdbc bbbab9b8
[samuel@me /tmp]$ bce 'obase=16 ; 200'
C8
---------------------------------------------------
Now I know which way the stack grows on my machine....
Comment 7 Michael Schwendt 2001-07-02 10:28:04 EDT
Created attachment 22447 [details]
patch against wu-ftpd-2.6.1-16
Comment 8 Michael Schwendt 2001-11-29 14:30:41 EST
Since this bug is still present with Enigma, the most recent errata release for
wu-ftpd (all four supported distribution versions!) would have been a great
opportunity to include my fix for this.
Comment 9 Michael Schwendt 2001-12-02 10:26:57 EST
This is turning into somewhat  of a motivation killer. :-(

On July 2nd I submitted a patch for this bug both here and to the wu-ftpd
mailing-list which is mentioned many times in the /usr/share/doc/wu-ftpd* files.
I haven't got a reply so far. Browsing the list archives it turns out, the
message arrived fine, but no one has bothered to reply to it nor follow the link
to this bug report.

Today I learned -- after having mailed to a different address found on
www.wu-ftpd.org -- that there was activity in the CVS a month later (on July
30th) and according to the description matches what my patch does. However,
where do I find that CVS server? Where do I find a pointer to it? I've tried
anonymous access to cvs.wu-ftpd.org, but couldn't login/connect. Additionally,
while trying to find a pointer to the CVS server I discover that bero@redhat.com
is a member of the wu-ftpd development group. This is rather frustrating.

*Please* confirm whether v1.71 of extensions.c in the CVS version includes my
fix for sure and whether this will be fixed for Red Hat Linux, too.
Comment 10 Michael Schwendt 2001-12-02 11:18:17 EST
The hidden nightly CVS snapshot tarball, which I've managed to find after
searching mailing-list archives for a longer time, includes a similar (albeit
partial IMHO) fix for this bug since July 30th.
Comment 11 Michael Schwendt 2001-12-02 11:18:23 EST
The hidden nightly CVS snapshot tarball, which I've managed to find after
searching mailing-list archives for a longer time, includes a similar (albeit
partial, IMHO) fix for this bug since July 30th.
Comment 12 Bernhard Rosenkraenzer 2001-12-13 08:53:48 EST
Fixed in 2.6.2-1

Note You need to log in before you can comment on or make changes to this bug.