Bug 39467
Summary: | creating directories via ftp results in root.root ownership | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Stephen Samuel <samuel> | ||||||
Component: | wu-ftpd | Assignee: | Bernhard Rosenkraenzer <bero> | ||||||
Status: | CLOSED RAWHIDE | QA Contact: | David Lawrence <dkl> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | 7.1 | CC: | bugs.michael, jbeima | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | i386 | ||||||||
OS: | Linux | ||||||||
URL: | Directories created owned by root | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2001-12-02 16:21:57 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Stephen Samuel
2001-05-07 20:40:59 UTC
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. Created attachment 17786 [details]
tar of ftp config files
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> 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 * * 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). 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.... Created attachment 22447 [details]
patch against wu-ftpd-2.6.1-16
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. 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 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. 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. 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. Fixed in 2.6.2-1 |