[ProFTPD-committers] [Bug 3604] Support DirFakeUser, DirFakeGroup and DirFakeMode for MLSD/MLST commands

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3604

TJ Saunders <***@castaglia.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Priority|P2 |P5
Status|NEW |ASSIGNED
CC| |***@castaglia.org
Platform|Other |All
Summary|Please support DirFakeUser, |Support DirFakeUser,
|DirFakeGroup and |DirFakeGroup and
|DirFakeMode in mod_facts |DirFakeMode for MLSD/MLST
| |commands
OS/Version|Linux |All
Severity|normal |enhancement

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3604

--- Comment #1 from TJ Saunders <***@castaglia.org> 2011-02-22 14:45:57 EST ---
One interesting aspect of this request is that LIST returns the user/group
ownership as name strings; MLSD/MLST return the user/group ownership as UID/GID
numbers. Thus supporting DirFakeUser/DirFakeGroup for MLSD/MLST will not be
quite the same. I am working on a patch to implement the requested support
using IDs, but wanted to make you aware of this difference.

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3604

--- Comment #2 from TJ Saunders <***@castaglia.org> 2011-02-22 15:44:16 EST ---
Created attachment 3549
--> http://bugs.proftpd.org/attachment.cgi?id=3549
Adds requested functionality

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3604

--- Comment #3 from John Zaitseff <***@zap.org.au> 2011-02-22 16:48:28 EST ---
That was quick work! Thanks for that!

Just one little comment, from browsing the patch and applying it (but not
running it!) on 1.3.4rc1: You change the mode in facts_mlinfo_get() using:

if (mode != NULL) {
/* We cheat here by simply overwriting the entire st.st_mode value with
* the DirFakeMode. This works because later operations on this data
* don't pay attention to the file type.
*/
info->st.st_mode = *mode;
}

I'm not sure how FTP clients interpret the mode: do they check for execute
permission on a directory, for example, before issuing CWD commands? If they
do, and even just for aesthetics, perhaps that code should read:

if (mode != NULL) {
if (S_ISDIR(info->st.st_mode)) {
info->st.st_mode = *mode | S_IXUSR | S_IXGRP | S_IXOTH;
} else {
info->st.st_mode = *mode;
}
}

Alternatively, of course, one could introduce a DirFakeModeDir ("DirFakeMode
for directories") configuration directive... All this for just presenting a
"nice" fake view of the directory tree!

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3604

--- Comment #4 from TJ Saunders <***@castaglia.org> 2011-02-22 20:12:16 EST ---
There is no "standard" way that FTP clients check anything before performing a
CWD. Some will just try, and see if it succeeds or fails; some will pay
attention to the permissions as returned by LIST/MLSD, and some won't.

The way that DirFakeMode is handled for LIST commands is exactly how I
implemented it for MLSD: the configured mode is what is displayed to the
client. An additional complication for MLSD commands is that the MLSD output
has a 'perms' artifact, for which there is no LIST equivalent. I left that
'perms' artifact unaffected by the configured DirFakeMode.

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3604

TJ Saunders <***@castaglia.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED

--- Comment #5 from TJ Saunders <***@castaglia.org> 2011-02-22 20:17:55 EST ---
And if needed, the admin can use <Directory> sections to display the fake mode
desired for directories versus files, e.g.:

<Directory path>
DirFakeMode 0555
</Directory>

<Directory path/*>
DirFakeMode 0444
</Directory>

Patch committed to CVS, with accompanying unit tests.

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3604

TJ Saunders <***@castaglia.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |CLOSED

--- Comment #6 from TJ Saunders <***@castaglia.org> 2011-04-06 03:46:33 EDT ---
Resolved in 1.3.4rc2.