--VrqPEDrXMn8OVzN4
Content-Type: multipart/mixed; boundary="AqsLC8rIMeq19msA"
Content-Disposition: inline
--AqsLC8rIMeq19msA
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Hi again,
On Thu, Jan 13, 2011 at 02:58:01PM +0100, Andreas Ericsson said:
> On 01/13/2011 01:43 PM, Stephen Gran wrote:
> > Hi,
> >=20
> > I'm looking slightly longer term at extending cgi.cfg to support using
> > contact_group names in the authorized_for* settings, and this is step
> > one on the road. If someone thinks the above is a bad idea (or if reuse
> > of code is a bad idea) let me know and I'll stop.
>=20
> There's one problem with this approach;
> The users in cgi.cfg don't have to be contacts. They only have to be able
> to log in to Nagios.
>=20
> With that in light, I wonder what happens when eu-admins is both a user
> (from the apache view of things) as well as a contactgroup, but not a
> contact. That's one of the things that absolutely has to keep working,
> or a lot of people's setups will break.
On Thu, Jan 13, 2011 at 07:21:37PM +0100, Jochen Bern said:
> On 01/13/2011 04:52 PM, Stephen Gran wrote:
> > On Thu, Jan 13, 2011 at 02:58:01PM +0100, Andreas Ericsson said:
> >> I wonder what happens when eu-admins is both a user
> >> (from the apache view of things) as well as a contactgroup, but not a
> >> contact. That's one of the things that absolutely has to keep working,
> >> or a lot of people's setups will break.
> > I was planning to use a marker to specify that it is a group, whether %
> > like sudo or @ like many other things
>=20
> 1. Both "%" and "@" are legal separators for e-mail addresses, which are
> getting more and more popular as "usernames" for all sorts of web UI
> logins. I doubt they're safe to forcefully overload, even as
> username[0].
> 2. I don't think that there's *any* printable character which is prima
> facie illegal in Basic Auth usernames. Not even the "," (and "=3D"?)
> that cgi.cfg sets aside as its separator char(s).
> 3. Suggestion: Make the marker configurable (so that admins can work
> around odd username[0]s already in use), with setting it to '\0' or
> somesuch effectively disabling the new feature (for the rare cases
> where the user base took pride in having really *every* printable
> character covered
.Sorry to let this sit for so long - the objections were all good ones,
and I had to go have a think, and then other things came up, as they
always do ...
Anyway, I think I've hit on something that may be useful, if you're
amenable. I'm proposing new cgi.cfg parameters that allow you to
specify contactgroups that are authorized for the various levels of auth
in addition to users. I think the attached patch does this, and in a
way that should ensure it doesn't interfere with existing practices.
Cheers,
--=20
--------------------------------------------------------------------------
| Stephen Gran | Labor, n.: One of the processes by |
| [email protected] | which A acquires property for B. -- |
| http://www.lobefin.net/~steve | Ambrose Bierce, "The Devil's |
| | Dictionary" |
--------------------------------------------------------------------------
--AqsLC8rIMeq19msA
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="0001-Allow-for-authorization-as-a-function-of-contact_gro.patch"
Content-Transfer-Encoding: quoted-printable
=46rom 8143501270dc83db7ded664f7f48d12f62e73f16 Mon Sep 17 00:00:00 2001
=46rom: Stephen Gran
Date: Sun, 24 Jul 2011 13:27:58 +0100
Subject: [PATCH] Allow for authorization as a function of contact_group mem=
bership
In large organizations, it is useful to be able to allow different teams
to have different levels of pre-defined global access. The simplest way
of doing that is to make the access group, rather than user based. This
introduces new cgi.cfg parameters so that we do not accidentally
overload
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]