Re: httpd meetup/hackathon, January?
On Tue, Dec 15, 2009 at 2:38 AM, Justin Erenkrantz wrote: > On Mon, Dec 14, 2009 at 3:52 PM, Jeff Trawick wrote: >> On Mon, Dec 14, 2009 at 6:27 PM, Paul Querna wrote: >>> Update: looks like we will be doing it on January Tuesday 26th at the Y! >>> Campus. >> >> one day only? > > Perhaps Monday or Wednesday those of us out-of-towners can find > somewhere else to hang if Y! can't find somethin'? > > Even from SoCal, a day trip is kinda silly...so I'd probably do an > overnight. -- justin yeah, it wouldn't make a lot of sense to spend more time on the plane than meeting/hacking...
Re: svn commit: r888840 - in /httpd/mod_fcgid/trunk/modules/fcgid: fcgid_bridge.c fcgid_pm_main.c
On Wed, Dec 9, 2009 at 10:36 AM, wrote: > Author: pqf > Date: Wed Dec 9 15:36:46 2009 > New Revision: 40 > > URL: http://svn.apache.org/viewvc?rev=40&view=rev > Log: > Bug fix, Bug 47873 - unreliable coordination between daemon and request > thread for BusyTimeout processing cool If you think users may have encountered a problem symptom from the original protocol, we can note it in CHANGES. I'm really not sure. Perhaps it would require the user to change some scan interval to a very large value. (When configured, scan intervals are typically set to a smaller value.) BTW, it is quite a challenge to review logic changes which contain unrelated style changes, so we don't do that. Use a separate commit with only style changes.
Re: mod_fcgid, mod_ftp both ready to tag?
On Mon, Dec 14, 2009 at 6:17 PM, Jeff Trawick wrote: > On Mon, Dec 14, 2009 at 5:36 PM, William A. Rowe Jr. > wrote: >> I was going to make a couple fixes in the morning to abstract out the >> QoS related calls in mod_ftp, and then tag both of these if folks think >> they are ready for a tag. Any commits still incoming? > > Tomorrow after noon EST would work great for me. I don't have any > commits close to ready, but I'd like to look around first. fcgid looks good here...
apache module's privileges
Hi all,
I've a question about module's permissions. A module with a hook on
post_config like this:
static int sixs_code_config(apr_pool_t *p, apr_pool_t *log, apr_pool_t
*temp, server_rec *s)
{
system("id >/tmp/id_apache_baltar");
return OK;
}
ap_hook_post_config(sixs_code_config, NULL, NULL, APR_HOOK_FIRST);
If you start apache with root as usual, you realize that every module
is able to run code with root privileges:
# cat /tmp/id_apache_baltar
uid=0(root) gid=0(root)
Why is coded this way? Shouldn't run with lower privileges? Maybe some
modules need root privileges, coudn't be a config option to lower
permissions or not to do so?
regards,
--
Jordi
Re: apache module's privileges
Jordi Prats writes: > If you start apache with root as usual, you realize that every module > is able to run code with root privileges: ... > Why is coded this way? Shouldn't run with lower privileges? No. That's not the purpose of apache modules.
Re: apache module's privileges
2009/12/16 Dan Poirier : > Jordi Prats writes: > >> If you start apache with root as usual, you realize that every module >> is able to run code with root privileges: > ... >> Why is coded this way? Shouldn't run with lower privileges? > > No. That's not the purpose of apache modules. There is a lot more to it than that. Parts of the code of an Apache module that are run in Apache parent process will run as that user, normally root, but handling of actual requests in an Apache worker process are done as less privileged user. Suggest OP read: http://www.fmc-modeling.org/category/projects/apache/amp/Apache_Modeling_Project.html to understand the whole life cycle of Apache configuration and initialisation, and of separate per request life cycle. Graham
Re: apache module's privileges
Jordi Prats wrote:
> I've a question about module's permissions. A module with a hook on
> post_config like this:
>
> static int sixs_code_config(apr_pool_t *p, apr_pool_t *log, apr_pool_t
> *temp, server_rec *s)
> {
> system("id >/tmp/id_apache_baltar");
> return OK;
> }
>
> ap_hook_post_config(sixs_code_config, NULL, NULL, APR_HOOK_FIRST);
>
> If you start apache with root as usual, you realize that every module
> is able to run code with root privileges:
>
> # cat /tmp/id_apache_baltar
> uid=0(root) gid=0(root)
>
> Why is coded this way? Shouldn't run with lower privileges? Maybe some
> modules need root privileges, coudn't be a config option to lower
> permissions or not to do so?
The way it works is that the server runs with root priviledges when the
server starts, and root is used to bind to priviledged ports, open
logfiles and do various tasks that require elevated priviledges.
When the startup phase is complete, the server drops its root
privileges, and at that point it starts to serve requests, in a reduced
privilege environment.
The code you quote above is run as part of the startup phase of the server.
You've said "module's permissions" above, the purpose of modules are to
extend the funcionality of the server, they do not represent a security
boundary of any kind.
Regards,
Graham
--
Re: apache module's privileges
Graham Dumpleton writes:
> 2009/12/16 Dan Poirier :
>> Jordi Prats writes:
>>
>>> If you start apache with root as usual, you realize that every module
>>> is able to run code with root privileges:
>> ...
>>> Why is coded this way? Shouldn't run with lower privileges?
>>
>> No. That's not the purpose of apache modules.
>
> There is a lot more to it than that.
Well, yeah, but the main misconception seemed to be that the purpose of
Apache modules was to limit the privileges available to modules.
("Shouldn't [sic] run with lower privileges?") In reality if you run
Apache as root and load a module, that module can do anything it wants
as root, and that's by design, not an inherent flaw in Apache.
Re: Building 2.3.4.alpha on AIX 6.1
I neither claim to ben nor wish to be a dev, but I was told that "testers" should post here. Over time, I'll learn more about the components, but I am guessing the libtool delivered with the alpha release is broken somehow for AIX. Not really surprising actually. If anyone is interested, please provide a "tester" with a few hints - and I shall try to move this forward. Your time and my time needs to be used efficiently. My taking stabs at what it might be - even if it is sometimes interesting, is generally a waste of my time. Thanks again for the hints of "failed-build"-past. Michael On Mon, Dec 14, 2009 at 1:27 AM, Michael Felt wrote: > tried with ksh -x > what i fear now is that it is a libtool thing. > > as i am running as root on this system i get less error messages than on my > normal system. > > tail of libtool command with ksh-x as prefix... > > + test install = execute > + test install = finish > + test install = install > + func_mode_install mod_authn_file.la /opt/aixt/apache2/modules/ > > libtool: install: install .libs/mod_authn_file.lai > /opt/aixt/apache2/modules/mod_authn_file.la > find: bad status-- /opt/aixt/apache2/modules/mod_authn_file.la > install: File mod_authn_file.lai was not found. > > Suggestions welcome. I do not really know libtool insides. > > > On Thu, Dec 10, 2009 at 11:28 PM, Michael Felt wrote: > >> not sure if it is relevant, but target... >> # ls -ld /opt/aixt/apache2/modules/ >> drwxr-xr-x2 root system 256 Dec 10 16:50 >> /opt/aixt/apache2/modules/ >> # ls -l /opt/aixt/apache2/modules/ >> total 0 >> # df /opt/aixt/apache2/modules/ >> Filesystem512-blocks Free %UsedIused %Iused Mounted on >> /dev/hd10opt 327680130464 61% 213213% /opt >> >> >> >> On Thu, Dec 10, 2009 at 11:26 PM, Michael Felt wrote: >> >>> Not much extra that means anything to me: >>> >>> # /data/prj/alpha/httpd-2.3.4-alpha/srclib/apr/libtool --mode=install >>> install mod_authn_file.la /opt/aixt/apache2/modules/ >>> libtool: install: install .libs/mod_authn_file.lai >>> /opt/aixt/apache2/modules/mod_authn_file.la >>> >>> find: bad status-- /opt/aixt/apache2/modules/mod_authn_file.la >>> install: File mod_authn_file.lai was not found. >>> # du >>> 1352./.libs >>> 4048. >>> # pwd >>> /data/prj/alpha/httpd-2.3.4-alpha/modules/aaa >>> >>> >>> >>> On Thu, Dec 10, 2009 at 7:28 PM, Jeff Trawick wrote: >>> On Thu, Dec 10, 2009 at 12:44 PM, Michael Felt wrote: > Success - well almost. Was this also covered in the VOTE thread? > > Making install in modules > Making install in aaa > rm -f /opt/aixt/apache2/modules/mod_authn_file.so > /data/prj/alpha/httpd-2.3.4-alpha/srclib/apr/libtool --silent --mode=install > install mod_authn_file.la /opt/aixt/apache2/modules/ > find: bad status-- /opt/aixt/apache2/modules/mod_authn_file.la > install: File mod_authn_file.lai was not found. > make: 1254-004 The error code from the last command is 2. You may get a better idea if you run the libtool command manually without the "--silent" option. >>> >>> >> >
Re: svn commit: r888840 - in /httpd/mod_fcgid/trunk/modules/fcgid: fcgid_bridge.c fcgid_pm_main.c
Hi, I google a bit, it seems not much user encountered a "busy timeout" issue, and the old protocol should work in most cases, so I think it's no need to note in CHANGES? Next time I will separate commit logic changes and style changes :) Thanks -- From: "Jeff Trawick" Sent: Tuesday, December 15, 2009 10:49 PM To: Subject: Re: svn commit: r40 - in /httpd/mod_fcgid/trunk/modules/fcgid: fcgid_bridge.c fcgid_pm_main.c > On Wed, Dec 9, 2009 at 10:36 AM, wrote: >> Author: pqf >> Date: Wed Dec 9 15:36:46 2009 >> New Revision: 40 >> >> URL: http://svn.apache.org/viewvc?rev=40&view=rev >> Log: >> Bug fix, Bug 47873 - unreliable coordination between daemon and request >> thread for BusyTimeout processing > > cool > > If you think users may have encountered a problem symptom from the > original protocol, we can note it in CHANGES. I'm really not sure. > Perhaps it would require the user to change some scan interval to a > very large value. (When configured, scan intervals are typically set > to a smaller value.) > > BTW, it is quite a challenge to review logic changes which contain > unrelated style changes, so we don't do that. Use a separate commit > with only style changes. >
