configfile_t.param

[Lou Langholtz <ld...@chpc.utah.edu>]

Can the usage for configfile_t.param stabilize soon at least for
.htaccess files? I have a module that needs to fstat() the .htaccess
file after its been opened by ap_parse_htaccess(). Can we maybe come up
with some macro that always serves to access the opened FILE *
independent of how the param field of configfile_t is used? This would
really help. Of course, maybe this is there already and someone just
needs to smack me in the head with its name.

Right now I'm in #ifdef hell using the MODULE_MAGIC_NUMBER define to get
around what seems to be changing usage from pre 1.3 days to 1.3b6 and
now another change in 1.3b7.

Thanks ;-)

Re: configfile_t.param

[Dean Gaudet <dg...@arctic.org>]

On Thu, 28 May 1998, Lou Langholtz wrote:

> Dean Gaudet wrote:
> 
> > How do you deal with mod_perl, which uses the general configfile_t
> > interface as well?  It's param is certainly nothing you can stat to get a
> > filename.
> >
> > i.e. I really don't think we can support what you want.  You can continue
> > to hack around it as you have, but we really can't provide you a macro for
> > it.
> 
> Well then the apache model seems broken.  A module's command_rec.func should be able to
> get the (FILE *) filehandle opened for the .htaccess file with the directive(s) that
> invoked it or at least a struct stat for that file.

What FILE *?  What file?  We're talking about generalised configuration
here.  Any module can provide a sequence of directives to the core, and
they do so through the configfile_t interface.  It just so happens that
one of those mechanisms is via a FILE *.  And you were abusing the
abstraction by treating a void * as a FILE *. 

Look at pcfg_open_custom() for an example of how to generate custom
configuration files. 

> Why does mod_perl need to muck with configfile_t in it's command_rec.func'tions? Why
> would any module even be allowed to alter this data that's past on to it during the
> directives invocation phase?

We're not talking here about crud that's parsed from configurations. 
We're talking here about the configuration "files" themselves.  They're
abstracted, they don't have to be a file.  As far as modifying the
configfile_t, you're right, a module shouldn't be allowed to do that in
its command handlers.  We could put const in there to prevent that.

> If a module needs to tack on its own internal data then we
> need to add something like a linked list to which modules can tack on there data to and
> that is designed so each module can identify its tacked data node and then muck with
> it.

This is unnecessary, there are already abstractions that allow for this.

I'm sorry but I think you're going to have to find some other way to
implement what you're trying to do.

Dean

Re: configfile_t.param

[Lou Langholtz <ld...@chpc.utah.edu>]

Dean Gaudet wrote:

> How do you deal with mod_perl, which uses the general configfile_t
> interface as well?  It's param is certainly nothing you can stat to get a
> filename.
>
> i.e. I really don't think we can support what you want.  You can continue
> to hack around it as you have, but we really can't provide you a macro for
> it.

Well then the apache model seems broken.  A module's command_rec.func should be able to
get the (FILE *) filehandle opened for the .htaccess file with the directive(s) that
invoked it or at least a struct stat for that file. Without that, modules will have to
do a stat() rather than a fstat() and have no assurance that the file they're stat'ing
is the same that was opened for the directive that invoked them to begin with. I may as
well re-parse the whole .htaccess file then. This is probably not as relevant to
Windoze but that really shouldn't matter. There's still stat info that could be useful.
Even a creation or modification  time could be useful. In Unix it certainly can be very
useful to know the uid/gid of the .htaccess file owner for security purposes. Less-Unix
centric file systems like AFS, and DFS also provide owner info so it's not only limited
to Unix. I don't know what NT's native file system interface provides but I'd hope that
its got a notion of an owner also.

Why does mod_perl need to muck with configfile_t in it's command_rec.func'tions? Why
would any module even be allowed to alter this data that's past on to it during the
directives invocation phase? If a module needs to tack on its own internal data then we
need to add something like a linked list to which modules can tack on there data to and
that is designed so each module can identify its tacked data node and then muck with
it.

Re: configfile_t.param

[Dean Gaudet <dg...@arctic.org>]

How do you deal with mod_perl, which uses the general configfile_t
interface as well?  It's param is certainly nothing you can stat to get a
filename.

i.e. I really don't think we can support what you want.  You can continue
to hack around it as you have, but we really can't provide you a macro for
it.

Dean

On Tue, 26 May 1998, Lou Langholtz wrote:

> Dean Gaudet wrote:
> 
> > But nothing linked into apache can append to a file unless that file is
> > writable by the www/nobody user.  So how are you appending?
> >
> > I'm just trying to figure out why we even need to support such a thing...
> > 'cause it's certainly not something we designed for.  And you certainly
> > can't get at the value in general.
> 
> Almost. The file must be writable by the webserver's primary group. This way the
> user can still own the file and access it themself.
> 
> This can be very useful. For example...
> 
> Using the right umask and a world writable sticky setgid httpd directory in the
> same filesystem, anyuser can easily make files writable to the web server and move
> those files to anywhere within their home directory. This file can then be used to
> do logging configured on a directory by directory basis. Of course the file
> descriptor has to be closed right after the append so as the server doesn't run
> out but this is a pratical way to enable users to see real time accesses to their
> web pages without giving them access to the access_log of everyones pages. If you
> want to see the code, let's drop the email list and email just directly
> back-and-forth. Thanks.
> 
> > On Tue, 26 May 1998, Lou Langholtz wrote:
> >
> > > Dean Gaudet wrote:
> > >
> > > > What do you need to do that for?
> > >
> > > To verify that the owner of the .htaccess file is also the owner of the file
> > > to which the module appends to. I haven't found anything like
> > > request_rec.finfo already available for the .htaccess file so the module has
> > > to get it itself and needed to get the info from the same .htaccess file that
> > > had gotten parsed to instruct the module to append its info to the .htaccess
> > > specified file. Have I missed something?
> > >
> > > > On Tue, 26 May 1998, Lou Langholtz wrote:
> > > >
> > > > > Can the usage for configfile_t.param stabilize soon at least for
> > > > > .htaccess files? I have a module that needs to fstat() the .htaccess
> > > > > file after its been opened by ap_parse_htaccess(). Can we maybe come up
> > > > > with some macro that always serves to access the opened FILE *
> > > > > independent of how the param field of configfile_t is used? This would
> > > > > really help. Of course, maybe this is there already and someone just
> > > > > needs to smack me in the head with its name.
> > > > >
> > > > > Right now I'm in #ifdef hell using the MODULE_MAGIC_NUMBER define to get
> > > > > around what seems to be changing usage from pre 1.3 days to 1.3b6 and
> > > > > now another change in 1.3b7.
> 
> 
> 

Re: configfile_t.param

[Lou Langholtz <ld...@chpc.utah.edu>]

Dean Gaudet wrote:

> But nothing linked into apache can append to a file unless that file is
> writable by the www/nobody user.  So how are you appending?
>
> I'm just trying to figure out why we even need to support such a thing...
> 'cause it's certainly not something we designed for.  And you certainly
> can't get at the value in general.

Almost. The file must be writable by the webserver's primary group. This way the
user can still own the file and access it themself.

This can be very useful. For example...

Using the right umask and a world writable sticky setgid httpd directory in the
same filesystem, anyuser can easily make files writable to the web server and move
those files to anywhere within their home directory. This file can then be used to
do logging configured on a directory by directory basis. Of course the file
descriptor has to be closed right after the append so as the server doesn't run
out but this is a pratical way to enable users to see real time accesses to their
web pages without giving them access to the access_log of everyones pages. If you
want to see the code, let's drop the email list and email just directly
back-and-forth. Thanks.

> On Tue, 26 May 1998, Lou Langholtz wrote:
>
> > Dean Gaudet wrote:
> >
> > > What do you need to do that for?
> >
> > To verify that the owner of the .htaccess file is also the owner of the file
> > to which the module appends to. I haven't found anything like
> > request_rec.finfo already available for the .htaccess file so the module has
> > to get it itself and needed to get the info from the same .htaccess file that
> > had gotten parsed to instruct the module to append its info to the .htaccess
> > specified file. Have I missed something?
> >
> > > On Tue, 26 May 1998, Lou Langholtz wrote:
> > >
> > > > Can the usage for configfile_t.param stabilize soon at least for
> > > > .htaccess files? I have a module that needs to fstat() the .htaccess
> > > > file after its been opened by ap_parse_htaccess(). Can we maybe come up
> > > > with some macro that always serves to access the opened FILE *
> > > > independent of how the param field of configfile_t is used? This would
> > > > really help. Of course, maybe this is there already and someone just
> > > > needs to smack me in the head with its name.
> > > >
> > > > Right now I'm in #ifdef hell using the MODULE_MAGIC_NUMBER define to get
> > > > around what seems to be changing usage from pre 1.3 days to 1.3b6 and
> > > > now another change in 1.3b7.

Re: configfile_t.param

[Dean Gaudet <dg...@arctic.org>]

On Wed, 27 May 1998, Gregory A Lundberg wrote:

> I think you can see where I'm headed .. what is needed is a generalized
> way of set?id'ing shared CGIs.

Oh yeah I agree with that.

Dean

Re: configfile_t.param

[Gregory A Lundberg <lu...@vr.net>]

On Tue, 26 May 1998, Dean Gaudet wrote:

> But nothing linked into apache can append to a file unless that file is
> writable by the www/nobody user.  So how are you appending?
> 
> I'm just trying to figure out why we even need to support such a thing... 
> 'cause it's certainly not something we designed for.  And you certainly
> can't get at the value in general.


Say 'should' instead of 'can'.

I think I can see where he's going.  Let's assume I'm writing a
hit-counter module and I'd like to append the some information about the
hit to a file.  I've got users doing just that right now with normal CGIs.
Please, let's not argue about the advisability of this; I know it's
questionable at best.

The question is: if I'm doing this is there some way to enforce inter-user
security?  Obviously I don't want user A adding the config for my
hit-coutner module into his .htaccess and pointing the log file at some
file in some other user's directory.  If I were doing this as a CGI I'd
have the ability to use suEXEC to enforce access rules.  But I'm doing it
in the web server as the anonymous web user.  

My first reaction would be 'Gee, I need to check all this stuff to be sure
it's safe' and I guess I could run off coding a bunch of checks on user
names and ownership and such.  But, seeing as how I hate reinventing
wheels, I'd look arround for some other way to get the job done .. and
lookit that: Apache provides it .. write the module as an external program
and run it _as_ the user in question.  In other words, write it as a CGI
and use suEXEC functionality.

This leaves just one point still open for the module author.  How do I
make it so the CGI can be shares (I know, ScriptAlias) yet still run
through suEXEC-style checks on security.

I think you can see where I'm headed .. what is needed is a generalized
way of set?id'ing shared CGIs.

----

Gregory A Lundberg		Senior Partner, VRnet Company
1441 Elmdale Drive              lundberg@vr.net
Kettering, OH 45409-1615 USA    1-800-809-2195

Re: configfile_t.param

[Dean Gaudet <dg...@arctic.org>]

But nothing linked into apache can append to a file unless that file is
writable by the www/nobody user.  So how are you appending?

I'm just trying to figure out why we even need to support such a thing... 
'cause it's certainly not something we designed for.  And you certainly
can't get at the value in general.

Dean

On Tue, 26 May 1998, Lou Langholtz wrote:

> Dean Gaudet wrote:
> 
> > What do you need to do that for?
> >
> > Dean
> 
> To verify that the owner of the .htaccess file is also the owner of the file
> to which the module appends to. I haven't found anything like
> request_rec.finfo already available for the .htaccess file so the module has
> to get it itself and needed to get the info from the same .htaccess file that
> had gotten parsed to instruct the module to append its info to the .htaccess
> specified file. Have I missed something?
> 
> Thanks Dean for asking ;-)
> 
> > On Tue, 26 May 1998, Lou Langholtz wrote:
> >
> > > Can the usage for configfile_t.param stabilize soon at least for
> > > .htaccess files? I have a module that needs to fstat() the .htaccess
> > > file after its been opened by ap_parse_htaccess(). Can we maybe come up
> > > with some macro that always serves to access the opened FILE *
> > > independent of how the param field of configfile_t is used? This would
> > > really help. Of course, maybe this is there already and someone just
> > > needs to smack me in the head with its name.
> > >
> > > Right now I'm in #ifdef hell using the MODULE_MAGIC_NUMBER define to get
> > > around what seems to be changing usage from pre 1.3 days to 1.3b6 and
> > > now another change in 1.3b7.
> > >
> > > Thanks ;-)
> > >
> 
> 
> 

Re: configfile_t.param

[Dean Gaudet <dg...@arctic.org>]

BTW, your technique also fails on unixes which allow folks to "chown away" 
files.  For example, on IRIX you can "chown someoneelse .htaccess", and it
will let you give away the file. 

Also on any unix I can:

    mkdir public_html/teehee
    cd public_html/teehee
    ln -s ~victim/public_html/.htaccess

and your fstat() will return the userid of the victim. 

Dean

On Tue, 26 May 1998, Lou Langholtz wrote:

> Dean Gaudet wrote:
> 
> > What do you need to do that for?
> >
> > Dean
> 
> To verify that the owner of the .htaccess file is also the owner of the file
> to which the module appends to. I haven't found anything like
> request_rec.finfo already available for the .htaccess file so the module has
> to get it itself and needed to get the info from the same .htaccess file that
> had gotten parsed to instruct the module to append its info to the .htaccess
> specified file. Have I missed something?
> 
> Thanks Dean for asking ;-)
> 
> > On Tue, 26 May 1998, Lou Langholtz wrote:
> >
> > > Can the usage for configfile_t.param stabilize soon at least for
> > > .htaccess files? I have a module that needs to fstat() the .htaccess
> > > file after its been opened by ap_parse_htaccess(). Can we maybe come up
> > > with some macro that always serves to access the opened FILE *
> > > independent of how the param field of configfile_t is used? This would
> > > really help. Of course, maybe this is there already and someone just
> > > needs to smack me in the head with its name.
> > >
> > > Right now I'm in #ifdef hell using the MODULE_MAGIC_NUMBER define to get
> > > around what seems to be changing usage from pre 1.3 days to 1.3b6 and
> > > now another change in 1.3b7.
> > >
> > > Thanks ;-)
> > >
> 
> 
> 

Re: configfile_t.param

[Lou Langholtz <ld...@chpc.utah.edu>]

Dean Gaudet wrote:

> What do you need to do that for?
>
> Dean

To verify that the owner of the .htaccess file is also the owner of the file
to which the module appends to. I haven't found anything like
request_rec.finfo already available for the .htaccess file so the module has
to get it itself and needed to get the info from the same .htaccess file that
had gotten parsed to instruct the module to append its info to the .htaccess
specified file. Have I missed something?

Thanks Dean for asking ;-)

> On Tue, 26 May 1998, Lou Langholtz wrote:
>
> > Can the usage for configfile_t.param stabilize soon at least for
> > .htaccess files? I have a module that needs to fstat() the .htaccess
> > file after its been opened by ap_parse_htaccess(). Can we maybe come up
> > with some macro that always serves to access the opened FILE *
> > independent of how the param field of configfile_t is used? This would
> > really help. Of course, maybe this is there already and someone just
> > needs to smack me in the head with its name.
> >
> > Right now I'm in #ifdef hell using the MODULE_MAGIC_NUMBER define to get
> > around what seems to be changing usage from pre 1.3 days to 1.3b6 and
> > now another change in 1.3b7.
> >
> > Thanks ;-)
> >

Re: configfile_t.param

[Dean Gaudet <dg...@arctic.org>]

What do you need to do that for?

Dean

On Tue, 26 May 1998, Lou Langholtz wrote:

> Can the usage for configfile_t.param stabilize soon at least for
> .htaccess files? I have a module that needs to fstat() the .htaccess
> file after its been opened by ap_parse_htaccess(). Can we maybe come up
> with some macro that always serves to access the opened FILE *
> independent of how the param field of configfile_t is used? This would
> really help. Of course, maybe this is there already and someone just
> needs to smack me in the head with its name.
> 
> Right now I'm in #ifdef hell using the MODULE_MAGIC_NUMBER define to get
> around what seems to be changing usage from pre 1.3 days to 1.3b6 and
> now another change in 1.3b7.
> 
> Thanks ;-)
>