Received: (qmail 25134 invoked by uid 2012); 1 Apr 1998 04:04:27 -0000 Message-Id: <19980401040427.25133.qmail@hyperreal.org> Date: 1 Apr 1998 04:04:27 -0000 From: Jay Soffian Reply-To: jay@cimedia.com To: apbugs@hyperreal.org Subject: adding auth_why to conn_rec X-Send-Pr-Version: 3.2 >Number: 2024 >Category: apache-api >Synopsis: adding auth_why to conn_rec >Confidential: no >Severity: non-critical >Priority: medium >Responsible: apache >State: suspended >Class: change-request >Submitter-Id: apache >Arrival-Date: Tue Mar 31 20:10:01 PST 1998 >Last-Modified: Mon Jun 15 08:00:24 PDT 1998 >Originator: jay@cimedia.com >Organization: >Release: any >Environment: n/a >Description: Currently, once a user is authorized access, there is no way for other modules nor CGI's to know why the user is authorized. They get AuthType and remote_user information, but knowing the reason for the authorization is also useful. For example, if a directory was protected with: require group foo bar and a user was granted access because they were a member of group bar, then conn_rec.auth_why would be set to "group bar". This information could be made available to CGI's by setting "AUTH_WHY" in util_script.c If this sounds resonable, let me know. I'm working on the required changes for 1.2.x. I can make similar changes to 1.3 and submit patches >How-To-Repeat: >Fix: >Audit-Trail: State-Changed-From-To: open-feedback State-Changed-By: dgaudet State-Changed-When: Wed Apr 1 03:50:53 PST 1998 State-Changed-Why: Just what would AUTH_WHY contain though? The reasons for access being permitted are essentially arbitrary... Dean From: Marc Slemko To: dgaudet@hyperreal.org Cc: jay@cimedia.com, Apache bugs database Subject: Re: apache-api/2024: adding auth_why to conn_rec Date: Wed, 1 Apr 1998 08:06:57 -0700 (MST) On 1 Apr 1998 dgaudet@hyperreal.org wrote: > [In order for any reply to be added to the PR database, ] > [you need to include in the Cc line ] > [and leave the subject line UNCHANGED. This is not done] > [automatically because of the potential for mail loops. ] > > > Synopsis: adding auth_why to conn_rec > > State-Changed-From-To: open-feedback > State-Changed-By: dgaudet > State-Changed-When: Wed Apr 1 03:50:53 PST 1998 > State-Changed-Why: > Just what would AUTH_WHY contain though? The reasons for access > being permitted are essentially arbitrary... I'm not sure I like the idea either. It starts going a bit crazy when you look at what modules can actually do for auth... What could be useful is a group field to complement the user field. Users and groups are a reasonably generic concept in many auth modules, so setting the group they were found in could be useful and is something that people do ask for a lot. From: Jay Soffian To: dgaudet@hyperreal.org, jay@cimedia.com, Apache bugs database , Marc Slemko Cc: Subject: Re: apache-api/2024: adding auth_why to conn_rec Date: Wed, 01 Apr 1998 11:19:26 -0500 +--Marc Slemko once said: | |On 1 Apr 1998 dgaudet@hyperreal.org wrote: | |> Just what would AUTH_WHY contain though? The reasons for access |> being permitted are essentially arbitrary... | |I'm not sure I like the idea either. It starts going a bit crazy when you |look at what modules can actually do for auth... | |What could be useful is a group field to complement the user field. |Users and groups are a reasonably generic concept in many auth modules, so |setting the group they were found in could be useful and is something that |people do ask for a lot. I agree, reasons for access being permitted are arbitrary, but all auth modules (at least with all modules I have looked at) act on a 'require ...'. It is my suggestion then that it is up to the module to decide what AUTH_WHY is set to. For the mod_auth files that handle 'require user ...', 'require group ...', and 'require valid-user', the suggested behavior is that they set AUTH_WHY to 'user ...', 'group ...', or 'valid-user', where in the case of 'user ...', '...' is the username that matched, and in the case of 'group ...', '...' is the group the user is a member of that matched. For auth_modules that grant access based on other criteria (for example, we are using a mod_auth_sys that we modified to work with NIS and accecpt 'require netgroup ...'), it is entirely up to module author to determine what 'AUTH_WHY' should be set to. As long as their behavior is documented, users of 'AUTH_WHY' shouldn't have any trouble knowing what to do. I would argue that is it even valid for an auth_ module not to set AUTH_WHY at all, and that a user of AUTH_WHY should treat this condition as 'the reason for access is unknown', and act accordingly. j. -- Jay Soffian UNIX Systems Administrator Cox Interactive Media State-Changed-From-To: feedback-suspended State-Changed-By: coar State-Changed-When: Mon Jun 15 08:00:24 PDT 1998 State-Changed-Why: Marking this for consideration and review during the next cycle. >Unformatted: [In order for any reply to be added to the PR database, ] [you need to include in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ]