You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by di...@covalent.net on 2002/07/10 18:09:26 UTC
Auth checker - long term goal..
Right now there are zillions of 1.3 auth modules around which have a
check_auth() stage which essentially does:
for each require line
do
if require valid-user
return OK
if require user
then
foreach uid
do
if r->user == uid
return ok
end
endif
end
due to cut-and-paste module creation; and the fact that some people want
to remove mod_auth.c from the server to not have mod_auth.c its own
authenticate_basic_user() against a file in the server.
I am looking at a cookie cutter approach for 2.0.... because in 2.0
everything is better (of course!) and I'd like to simplify things as much
as possible.
So if you look at mod_auth_dbm.c in 2.0 we rely on mod_auth.c to be to be
able to do things like
require user foo
even when we are not using AuthUserFile.
Aside: (And when mod_auth is not LoadModule-d in, but mod_auth_dbm is -
things just got a bit more interesting -as we do not keep a tally
as to if each require line is actually used or parsed sensible by
anyone - so interesting things can sneak past the admin which does
not test his server after a change - **).
So I'd like to remove the (not that technically sound) excuses for people
not to have mod_auth.c in the server anymore. I.e. perception mostly.
Would it be fair to say that
-> We want to make it as easy as possible for those old legacy
mod_auth_* modules to be ported - and as a guideline do not want
them do their own 'require user' stuff anymore.
We want that done central. In a standard module.
-> If we add to mod_auth.c a 'AuthUserFile 'OFF"' or some other
very 'cheap' VISIBLE disbable then there is no reason left for
mod_auth modules to do their own 'require user/require valid user'
work. This would be just to reasure people; the default is NULL
anyway (*). Or alternatively an Auth directive picked up by
mod_auth which uses the ap_auth_type or the source of the info.
Or better perhaps
-> Or alternatively mod_auth is split into a mod_auth and a
a mod_require. The first does the File based username
checking; the latter does the "require valid-user", "require
user foo" checks. 'require group' can stay in mod_auth or
go into a mod_auth_group.
With that out of the way; In the long term may want to do the same for
groups checking which now fundamentally must happen in each module as
group findings are not shared.
I.e. just like we have a r->user have a r->groups field (a table rather
than a char*) which lists the groups the user is part off. (Though I
recognize that there will always be group auth modules which need to to
the reverse; i.e. check if a user is in a list of groups - or, for these
cases, an additional check_group_access handler mirroring the user_access
stage).
Any thoughds ? Note that part of the above problem is perception causing
the duplication of mod_auth because of the file association.
Dw
--
Dirk-Willem van Gulik
Ad *: We'd need to touch up the error messages of mod_auth a little.
Ad **: Which of course would need another hook... and run method in
apache 3.0.
Re: Auth checker - long term goal..
Posted by Aaron Bannert <aa...@clove.org>.
On Wed, Jul 10, 2002 at 11:19:31AM -0700, Brian Pane wrote:
> From my perspective, the event that should cause us to branch for
> a 2.1 or 3.0 release isn't "this code change is too drastic for 2.0"
> but rather: "this new feature that's useful to customers is impossible
> to build or maintain on top of the 2.0 framework." And hopefully it
> will be a while before we get to that point: 2.0's design allows us
> to make a *lot* of changes without requiring a rearchitecture of the
> core server.
>
> I'd really like to see a roadmap that says something like:
>
> Remaining 2.0 maintenance releases:
> - Incremental performance improvements
> - Bug fixes
> - New modules and MPMs as needed
>
> 2.1:
> - "Sandbox" processes in which to run untrusted plug-in code safely
> - Further refactoring of the core daemon to make it easier
> to support non-HTTP protocols
>
> 3.0:
> - New architecture for massive scalability
I disagree, but not strongly. The reason I don't like the idea of a strict
roadmap of features is because it has the tendency to place restrictions
on what people can work on, and that isn't The Apache Way. The ad-hoc
posting of patches and acceptance of those units of work has a great
benefit in our volunteer community. If the roadmap is simply a list of
cool things we'd like to add, and where some of the developers think
the project is going, then it can be encouraging for new development.
As soon as it becomes a tool to ban features from being incorporated
into the tree, it will discourage spontaneous volunteerism. I'd much
rather see the roadmap as our collective brainstorm.
In other words, we should just keep going, looking at one patch at
a time, and as soon as someone takes the reigns and produces something
revolutionary that we aren't quite ready to force onto our 2.0 users,
then it may be time to think about a branch.
-aaron
Re: Auth checker - long term goal..
Posted by Brian Pane <br...@apache.org>.
Aaron Bannert wrote:
>On Wed, Jul 10, 2002 at 10:44:46AM -0700, Ryan Bloom wrote:
>
>
>>I still believe that everything that is currently in ROADMAP can and
>>should be implemented in 2.0.
>>
I agree.
>And my point is we won't know until there is a patch that solves
>one of the roadmap problems. Only then will we be able to decide.
>
The problem I have with the roadmap is that it's mostly a list
of implementation changes. What it should be is a list of product
features: things that are meaningful to a customer of Apache (whether
that customer is an end-user or a third-party developer), not just
meaningful to those of us who work on the httpd code.
From my perspective, the event that should cause us to branch for
a 2.1 or 3.0 release isn't "this code change is too drastic for 2.0"
but rather: "this new feature that's useful to customers is impossible
to build or maintain on top of the 2.0 framework." And hopefully it
will be a while before we get to that point: 2.0's design allows us
to make a *lot* of changes without requiring a rearchitecture of the
core server.
I'd really like to see a roadmap that says something like:
Remaining 2.0 maintenance releases:
- Incremental performance improvements
- Bug fixes
- New modules and MPMs as needed
2.1:
- "Sandbox" processes in which to run untrusted plug-in code safely
- Further refactoring of the core daemon to make it easier
to support non-HTTP protocols
3.0:
- New architecture for massive scalability
--Brian
Re: Auth checker - long term goal..
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 12:56 PM 7/10/2002, Aaron Bannert wrote:
>On Wed, Jul 10, 2002 at 10:44:46AM -0700, Ryan Bloom wrote:
> > I still believe that everything that is currently in ROADMAP can and
> > should be implemented in 2.0.
>
>And my point is we won't know until there is a patch that solves
>one of the roadmap problems. Only then will we be able to decide.
EXACTLY!
If someone offers a patch to split various authn/authz hooks, while
retaining the existing hooks so that 3rd parties don't -need- to adopt
the new features, then terrific.
And if we like, we can mark the old methods as deprecated and soon
to disappear in 2.1.
Bill
Re: Auth checker - long term goal..
Posted by Aaron Bannert <aa...@clove.org>.
On Wed, Jul 10, 2002 at 10:44:46AM -0700, Ryan Bloom wrote:
> I still believe that everything that is currently in ROADMAP can and
> should be implemented in 2.0.
And my point is we won't know until there is a patch that solves
one of the roadmap problems. Only then will we be able to decide.
-aaron
RE: Auth checker - long term goal..
Posted by Ryan Bloom <rb...@covalent.net>.
I still believe that everything that is currently in ROADMAP can and
should be implemented in 2.0.
Ryan
----------------------------------------------
Ryan Bloom rbb@covalent.net
645 Howard St. rbb@apache.org
San Francisco, CA
> -----Original Message-----
> From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> Sent: Wednesday, July 10, 2002 10:37 AM
> To: dev@httpd.apache.org
> Cc: dev@httpd.apache.org
> Subject: Re: Auth checker - long term goal..
>
> At 12:07 PM 7/10/2002, Aaron Bannert wrote:
> >On Wed, Jul 10, 2002 at 09:39:29AM -0700, Ryan Bloom wrote:
> > > I'm sorry, but that is completely bogus. If the API needs to
change
> to
> > > make things better, then change the API. Stop trying to open a
new
> dev
> > > branch when the current one is still moving forward quickly. We
have
> > > this discussion every few weeks now, and every few weeks the 2.1
repo
> > > gets shot down, because these changes belong in 2.0.
> >
> >I don't recall any strong opinions on this other than from you and
> >OtherBill.
> >
> >My feeling is somewhere between. We shouldn't rush off and branch 2.1
if
> >we don't have any specific goals to solve, nor should we be forcing
major
> >changes upon our 2.0 users. The point of inflection comes when
someone
> >produces a patch for 2.0 that we aren't quite ready to swallow. As
soon
> >as that happens we have a perfect excuse for a branch.
>
> The list is in ROADMAP. Every item there was effectively vetoed for
the
> current development tree as too radical an overhaul. Each was pointed
to
> "the next version, we are {too close to|already for|already have the
ga}
> release".
> Improve the ROADMAP. Spell out what 2.1/3.0 will offer.
>
> Things like needing to track r->openfile instead of r->filename,
needing
> to
> follow a new convention to write auth modules {splitting authn/authz
into
> smaller useful chunks, but with no back-compat}, proving pushback as a
> more effective authoring and performance filtering model (that
accomodates
> both input and output filters in the same schema), async
cross-threaded
> requests, and so forth.
>
> >Soooo.... -1 for 2.1 until we have such a patch.
>
> I agree we aren't ready for 2.1 until 2.0 is stable and relatively bug
> free.
> I thought someone a year and a half ago actually threw one out there
> for some of the auth, but I too want the group to stay focused on
making
> 2.0 a serious threat to 1.3 and other servers. Without breaking
existing
> 3rd party modules beyond rebuilding, and occasional API changes, that
> are absolutely required. API changes that break 3rd party 2.0
modules,
> just "because it's better|cooler|faster", are bogus now that we are
GA.
>
> Bill
>
Re: Auth checker - long term goal..
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 12:07 PM 7/10/2002, Aaron Bannert wrote:
>On Wed, Jul 10, 2002 at 09:39:29AM -0700, Ryan Bloom wrote:
> > I'm sorry, but that is completely bogus. If the API needs to change to
> > make things better, then change the API. Stop trying to open a new dev
> > branch when the current one is still moving forward quickly. We have
> > this discussion every few weeks now, and every few weeks the 2.1 repo
> > gets shot down, because these changes belong in 2.0.
>
>I don't recall any strong opinions on this other than from you and
>OtherBill.
>
>My feeling is somewhere between. We shouldn't rush off and branch 2.1 if
>we don't have any specific goals to solve, nor should we be forcing major
>changes upon our 2.0 users. The point of inflection comes when someone
>produces a patch for 2.0 that we aren't quite ready to swallow. As soon
>as that happens we have a perfect excuse for a branch.
The list is in ROADMAP. Every item there was effectively vetoed for the
current development tree as too radical an overhaul. Each was pointed to
"the next version, we are {too close to|already for|already have the ga}
release".
Improve the ROADMAP. Spell out what 2.1/3.0 will offer.
Things like needing to track r->openfile instead of r->filename, needing to
follow a new convention to write auth modules {splitting authn/authz into
smaller useful chunks, but with no back-compat}, proving pushback as a
more effective authoring and performance filtering model (that accomodates
both input and output filters in the same schema), async cross-threaded
requests, and so forth.
>Soooo.... -1 for 2.1 until we have such a patch.
I agree we aren't ready for 2.1 until 2.0 is stable and relatively bug free.
I thought someone a year and a half ago actually threw one out there
for some of the auth, but I too want the group to stay focused on making
2.0 a serious threat to 1.3 and other servers. Without breaking existing
3rd party modules beyond rebuilding, and occasional API changes, that
are absolutely required. API changes that break 3rd party 2.0 modules,
just "because it's better|cooler|faster", are bogus now that we are GA.
Bill
Re: Auth checker - long term goal..
Posted by Aaron Bannert <aa...@clove.org>.
On Wed, Jul 10, 2002 at 09:39:29AM -0700, Ryan Bloom wrote:
> I'm sorry, but that is completely bogus. If the API needs to change to
> make things better, then change the API. Stop trying to open a new dev
> branch when the current one is still moving forward quickly. We have
> this discussion every few weeks now, and every few weeks the 2.1 repo
> gets shot down, because these changes belong in 2.0.
I don't recall any strong opinions on this other than from you and
OtherBill.
My feeling is somewhere between. We shouldn't rush off and branch 2.1 if
we don't have any specific goals to solve, nor should we be forcing major
changes upon our 2.0 users. The point of inflection comes when someone
produces a patch for 2.0 that we aren't quite ready to swallow. As soon
as that happens we have a perfect excuse for a branch.
Soooo.... -1 for 2.1 until we have such a patch.
-aaron
Re: Auth checker - long term goal..
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 03:32 PM 7/11/2002, you wrote:
>Ryan Bloom wrote:
> >
> > I'm sorry, but that is completely bogus. If the API needs to change to
> > make things better, then change the API.
>
>I disagree. *Changing* the API is the bogus aspect. *Enhancing*
>it so that new split auth/authz functionality is available, without
>breaking anyone's existing auth/authz modules, does not increase
>the bogon flux anywhere nearly as much. "Change bad; enhance good."
Well said, RoUS.
Re: Auth checker - long term goal..
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Ryan Bloom wrote:
>
> I'm sorry, but that is completely bogus. If the API needs to change to
> make things better, then change the API.
I disagree. *Changing* the API is the bogus aspect. *Enhancing*
it so that new split auth/authz functionality is available, without
breaking anyone's existing auth/authz modules, does not increase
the bogon flux anywhere nearly as much. "Change bad; enhance good."
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
Re: Auth checker - long term goal..
Posted by Pier Fumagalli <pi...@betaversion.org>.
Ryan Bloom <rb...@covalent.net> wrote:
> I'm sorry, but that is completely bogus. If the API needs to change to
> make things better, then change the API. Stop trying to open a new dev
> branch when the current one is still moving forward quickly. We have
> this discussion every few weeks now, and every few weeks the 2.1 repo
> gets shot down, because these changes belong in 2.0.
I tend to agree with Ryan although I'm no committer... Wouldn't want to see
httpd to end up like Tomcat did...
Pier
--
[Perl] combines all the worst aspects of C and Lisp: a billion of different
sublanguages in one monolithic executable. It combines the power of C with
the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]
RE: Auth checker - long term goal..
Posted by Ryan Bloom <rb...@covalent.net>.
> From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> Sent: Wednesday, July 10, 2002 9:31 AM
> To: dev@httpd.apache.org
> Cc: dirkx@covalent.net; dev@httpd.apache.org
> Subject: RE: Auth checker - long term goal..
>
> At 11:22 AM 7/10/2002, Ryan Bloom wrote:
> > > From: dirkx@covalent.net [mailto:dirkx@covalent.net]
> > >
> > >
> > > On Wed, 10 Jul 2002, Ryan Bloom wrote:
> > >
> > > > > user foo" checks. 'require group' can stay in mod_auth or
> > > > > go into a mod_auth_group.
> > > >
> > > > Didn't we decide to take this approach like a year ago?
> > >
> > > Hmm - been asleep as usual - if so - I'd love to make that split
right
> > > away ! I feel a patch coming...
> >
> >I am pretty sure that splitting auth from authz is even listed in the
> >STATUS file.
>
> It is in fact in the ROADMAP file. See there.
>
> Then feel free to decorate with more details. I agree with Dirk, it's
> too much to ask all porters/module authors to rework their entire
> stratagem in the production branch.
>
> It's time for 2.1. We don't need to make .1 a total overhaul, simply
> address the things we've wanted for some time, that are likely to
> inflict new bugs on 3rd party modules.
I'm sorry, but that is completely bogus. If the API needs to change to
make things better, then change the API. Stop trying to open a new dev
branch when the current one is still moving forward quickly. We have
this discussion every few weeks now, and every few weeks the 2.1 repo
gets shot down, because these changes belong in 2.0.
Ryan
RE: Auth checker - long term goal..
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 11:22 AM 7/10/2002, Ryan Bloom wrote:
> > From: dirkx@covalent.net [mailto:dirkx@covalent.net]
> >
> >
> > On Wed, 10 Jul 2002, Ryan Bloom wrote:
> >
> > > > user foo" checks. 'require group' can stay in mod_auth or
> > > > go into a mod_auth_group.
> > >
> > > Didn't we decide to take this approach like a year ago?
> >
> > Hmm - been asleep as usual - if so - I'd love to make that split right
> > away ! I feel a patch coming...
>
>I am pretty sure that splitting auth from authz is even listed in the
>STATUS file.
It is in fact in the ROADMAP file. See there.
Then feel free to decorate with more details. I agree with Dirk, it's
too much to ask all porters/module authors to rework their entire
stratagem in the production branch.
It's time for 2.1. We don't need to make .1 a total overhaul, simply
address the things we've wanted for some time, that are likely to
inflict new bugs on 3rd party modules.
Bill
RE: Auth checker - long term goal..
Posted by Ryan Bloom <rb...@covalent.net>.
> From: dirkx@covalent.net [mailto:dirkx@covalent.net]
>
>
> On Wed, 10 Jul 2002, Ryan Bloom wrote:
>
> > > user foo" checks. 'require group' can stay in mod_auth or
> > > go into a mod_auth_group.
> >
> > Didn't we decide to take this approach like a year ago?
>
> Hmm - been asleep as usual - if so - I'd love to make that split right
> away ! I feel a patch coming...
I am pretty sure that splitting auth from authz is even listed in the
STATUS file.
Ryan
RE: Auth checker - long term goal..
Posted by di...@covalent.net.
On Wed, 10 Jul 2002, Ryan Bloom wrote:
> > user foo" checks. 'require group' can stay in mod_auth or
> > go into a mod_auth_group.
>
> Didn't we decide to take this approach like a year ago?
Hmm - been asleep as usual - if so - I'd love to make that split right
away ! I feel a patch coming...
Dw
RE: Auth checker - long term goal..
Posted by di...@covalent.net.
> > Ad **: Which of course would need another hook... and run method in
> > apache 3.0.
>
> There is no reason to wait for Apache 3.0 to add a new hook. The whole
> reason for the hook abstraction was to make adding hooks painless for
> module authors.
Well - but this is a rather fundamental API change - at it would make the
require array out of bounds; i.e. it changes the way you would interact
wiht that array in a fairly fundamental way - and would make it more like
how want interacts with the command rec or general hook passing.
Dw
RE: Auth checker - long term goal..
Posted by Sander Striker <st...@apache.org>.
> From: Ryan Bloom [mailto:rbb@covalent.net]
> Sent: 10 July 2002 18:15
> To: dev@httpd.apache.org
> Subject: RE: Auth checker - long term goal..
>
>
> <snipped greatly for brevity>
>
> > -> Or alternatively mod_auth is split into a mod_auth and a
> > a mod_require. The first does the File based username
> > checking; the latter does the "require valid-user", "require
> > user foo" checks. 'require group' can stay in mod_auth or
> > go into a mod_auth_group.
>
> Didn't we decide to take this approach like a year ago?
We did. IIRC, we wanted to have the split before 2.0 was released.
There was something that held this change back. Please check the
thread before committing anything.
Sander
RE: Auth checker - long term goal..
Posted by Ryan Bloom <rb...@covalent.net>.
<snipped greatly for brevity>
> -> Or alternatively mod_auth is split into a mod_auth and a
> a mod_require. The first does the File based username
> checking; the latter does the "require valid-user", "require
> user foo" checks. 'require group' can stay in mod_auth or
> go into a mod_auth_group.
Didn't we decide to take this approach like a year ago?
> With that out of the way; In the long term may want to do the same for
> groups checking which now fundamentally must happen in each module as
> group findings are not shared.
>
> I.e. just like we have a r->user have a r->groups field (a table
rather
> than a char*) which lists the groups the user is part off. (Though I
> recognize that there will always be group auth modules which need to
to
> the reverse; i.e. check if a user is in a list of groups - or, for
these
> cases, an additional check_group_access handler mirroring the
user_access
> stage).
>
> Any thoughds ? Note that part of the above problem is perception
causing
> the duplication of mod_auth because of the file association.
>
> Dw
> --
> Dirk-Willem van Gulik
>
> Ad *: We'd need to touch up the error messages of mod_auth a little.
> Ad **: Which of course would need another hook... and run method in
> apache 3.0.
There is no reason to wait for Apache 3.0 to add a new hook. The whole
reason for the hook abstraction was to make adding hooks painless for
module authors.
Ryan