Re: [cgiwrap-users] 'with rewrite' option

[Joe H. <on...@dc...>]

On Fri, 19 Oct 2001, Mark Montague wrote:
> On Fri, 19 Oct 2001, Joe Hourcle wrote:
>
> > 	--with-rewrite=FILE
> > 	       use a file to rewrite user directories
> >
> > Unfortunately, I can't seem to find documentation on what the format of
> > this file is.  Can someone point me in the right direction?
>
> The format of the file is lines of the form:
>
> username:relative/path/to/cgi-bin/directory/from/home/directory

Thanks.

> Documentation begins on line 1149 of the file util.c :)

even after a semester of c, and a class that I mistakenly took on cpp
[never again will I forget to check if it's an 'introduction to
programming' type class], I've been kind of shying away from digging
through C code.

Thanks for the reference, though.

> > [I mean, hell, I ideally, I'd love to be able to tell it to completely
> > ignore the password file, and use something else, but without breaking
> > digging through the code, I'm going to assume that it's just using
> > standard system calls, [which doesn't necessarily use the standard
> > password file, of course]]
>
> Well, digging through the code, on line 90 of cgiwrap.c we have:
>
>         /* Now, get whatever information that is available about that */
>         /* user - fetch this information from the passwd file or NIS */
>         if ( !(user = getpwnam(userStr)) )
>         {
>                 MSG_Error_NoSuchUser(userStr);
>         }
>
> So you don't need a /etc/passwd file as long as your getpwnam()
> function in the standard library knows where to get user information.
> In other words, your assumption appears to be a valid one.

Well, unfortunately, we're not using a fully standard config [LDAP
authentication of users, but with the 'groups accounts' being maintained
in the password file], so I was just planning on keeping a cgiwrap.allow
file to ensure that the only the accounts for the group, and not the users
would be able to execute files.

[And to make it worse, it's a cluster, and I was hoping to be lazy, and
not have to propogate new users into the password files of each node]


> By the way, many thanks to Nathan for a great program!  I think it
> is much better than suEXEC.

Definately.  As annoying as the list of options is under './configure
--help', I'm actually finding a few uses where some of the that I've
ignored are becoming necessary [--without-check-group-writable for one]

And, not to mention, that I can't use suExec on netscape servers.


-----
Joe Hourcle