b***@horde.net
2011-01-13 21:50:27 UTC
http://bugs.proftpd.org/show_bug.cgi?id=3576
--- Comment #1 from TJ Saunders <***@castaglia.org> 2011-01-13 16:50:26 ---
This is not going to be as straightforward a change as I had hoped.
The issue is that both the mod_cap and mod_ifsession modules have POST_CMD
phase handlers for the PASS command. In order for mod_ifsession's merging of
directives (and thus to support the requested functionality), its POST_CMD
handler needs to run before mod_cap's POST_CMD handler.
The order in which command handlers are run depends on the module load order:
last module loaded, first module in dispatch chain.
The mod_cap module is *automatically* added to the list of modules by proftpd's
configure script, when it detects linuxprivs/capabilities support in the host.
This automatic enabling means that mod_cap will always end up after
mod_ifsession in the module load order -- and thus means that mod_cap's
POST_CMD handler for the PASS command will run before mod_ifsession.
This could all be handled easily for DSO/shared modules -- except that the
configure script does not allow the mod_cap module to be built as a shared
module. (Probably because it *is* auto-enabled, and the script would need to
know whether to autoenable it as a static or a shared module.)
One possibility is to modify the configure script to always make sure that
mod_ifsession, if it appears in the static module list, is always last,
regardless of anything else. I don't think this would break any existing
configs, and it would ensure that The Right Thing(tm) is always done for
mod_ifsession (rather than having to remind people to do this).
--- Comment #1 from TJ Saunders <***@castaglia.org> 2011-01-13 16:50:26 ---
This is not going to be as straightforward a change as I had hoped.
The issue is that both the mod_cap and mod_ifsession modules have POST_CMD
phase handlers for the PASS command. In order for mod_ifsession's merging of
directives (and thus to support the requested functionality), its POST_CMD
handler needs to run before mod_cap's POST_CMD handler.
The order in which command handlers are run depends on the module load order:
last module loaded, first module in dispatch chain.
The mod_cap module is *automatically* added to the list of modules by proftpd's
configure script, when it detects linuxprivs/capabilities support in the host.
This automatic enabling means that mod_cap will always end up after
mod_ifsession in the module load order -- and thus means that mod_cap's
POST_CMD handler for the PASS command will run before mod_ifsession.
This could all be handled easily for DSO/shared modules -- except that the
configure script does not allow the mod_cap module to be built as a shared
module. (Probably because it *is* auto-enabled, and the script would need to
know whether to autoenable it as a static or a shared module.)
One possibility is to modify the configure script to always make sure that
mod_ifsession, if it appears in the static module list, is always last,
regardless of anything else. I don't think this would break any existing
configs, and it would ensure that The Right Thing(tm) is always done for
mod_ifsession (rather than having to remind people to do this).
--
Configure bugmail: http://bugs.proftpd.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Configure bugmail: http://bugs.proftpd.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.