[Nagios-users] Advanced permissions/user properties

[Tobias Klausmann]

Hi!

I've got a problem that I don't how to solve best in Nagios. I
think other people have run into the same problem (I know that
someone has run into a /similar/ problem).

I'm running 2.5 on a mid-sized installations (~300 hosts, ~2500
services). Thing is, our projects/(host|service)groups vary
wildly in who is responsible for them. Unfortunately, all these
projects are also heavily intertwined in their dependencies.

Say we have a web mail project A. This consists of several
web servers, databases and the like. It is heavily dependent on
the LDAP project B and the mail server project C. While B and C
have the same group of admins, project A is managed by an
entirely different group of people.

As such, we have configured Nagios that the group that is
responsible for project can only see the machines of project A and
the "B-and-C-people" can only see B and C.

Everything is peachy.

Except. Sometimes, project A may look like it's broken (pages
time out etc). But in reality, there's a spam attack and the
project B (the LDAP infrastructure) is so slow it simply grinds
to a halt. In this case it would obviously be nice if the people
from project A could see that project B is slow. Yet they should
not be able to change the notification options/acknowledgements
etc etc of projects B or C.

The altinity people have created a patch for the "view some,
change none" scenario[0]. Unfortunately, what I'd need is a
mechanism for the "view some, change a few" scenario I outlined
above.

How do others deal with this kind of problem? I'm sure we're not
the only ones who've run into it.

As of currently, our best guess would be to create
pseudo-accounts (like john.foo and john.foo-admin) and hack the
CGI(s) to only allow the commands from -admin accounts which are
in the notification list (with notification options set to "n").
We already do this to let people see machines they don't
mailed/paged/called about.

Regards,
Tobias

[0] http://altinity.blogs.com/dotorg/2006/02/a_view_some_cha.html

[Az]

Post by Tobias Klausmann
The altinity people have created a patch for the "view some,
change none" scenario[0]. Unfortunately, what I'd need is a
mechanism for the "view some, change a few" scenario I outlined
above.

Is that to say that "view _all_, change some" wouldn't work for you?
That's how we're working at present, out-of-the-box. While restricting
viewing might reduce mental clutter for those concerned*, I can't see
why being able to see everything is a big deal (unless you're displaying
some super sensitive information in Nagios which is a totally different
topic).

See
http://nagios.sourceforge.net/docs/2_0/configcgi.html#authorized_for_all_hosts
and
http://nagios.sourceforge.net/docs/2_0/configcgi.html#authorized_for_all_services.

*Our service centre can see everything, but we used service groups to
provide "rolled up" views to keep it simple for them. All our engineers
can see everything so when they spot an issue with someone elses kits
that impacts their own, they can find out what the issue is and who to
poke in the eye with a burnt stick to get it fixed. We found that trying
to hide stuff just blinkered people and made them only responsive to
their own issues ("not my server. not my problem.") which results in
poor customer service at the end of the day.

[Tobias Klausmann]

Hi!

Post by Az

Post by Tobias Klausmann
The altinity people have created a patch for the "view some,
change none" scenario[0]. Unfortunately, what I'd need is a
mechanism for the "view some, change a few" scenario I outlined
above.

Is that to say that "view _all_, change some" wouldn't work for you?
That's how we're working at present, out-of-the-box. While restricting
viewing might reduce mental clutter for those concerned*, I can't see
why being able to see everything is a big deal (unless you're displaying
some super sensitive information in Nagios which is a totally different
topic).

Well it's not super sensitive but when we started deploying
Nagios we were very happy to not clutter the webpages for everybody
(how we Nagios admins cope is another story ;)). We're currently
looking into hacking cmd.cgi to

a) log all issued commands with username and ip
and
b) do some permission checking

Unfortunately b) will leave us with yet another othogonal user
account type. Currently, most users have three accounts:
first.last, first.last-sms, first.last-email, first.last-phone.
The first account allows them to log onto the website and view
stuff, the other three are used to configure the respective
notification types (the first account has notifications disabled
entirely). This has the advantage that not everybody that wants
to see a host has to get any of the used notification types.
Unfortunately, you can not easily pull apart "view" and "disable
stuff" this way, hence my initial question.

The Nagios permission system is a bit lacking in this respect. As
far as I can tell from Ethan's presentation about 3.0, that won't
change (much) with the next version. It's not like I have the
perfect way to specify such fine-grained perms in my head,
either.

Post by Az
*Our service centre can see everything, but we used service groups to
provide "rolled up" views to keep it simple for them. All our engineers
can see everything so when they spot an issue with someone elses kits
that impacts their own, they can find out what the issue is and who to
poke in the eye with a burnt stick to get it fixed. We found that trying
to hide stuff just blinkered people and made them only responsive to
their own issues ("not my server. not my problem.") which results in
poor customer service at the end of the day.

While I agree with you mostly, we also offer Nagios monitoring to
our customers. This is turn means that we have to seperate them
in some way (it wouldn't be cool if all customers saw each
other's hosts and services). This is a hard requirement that I
can't move a single inch on (rather: my boss won't let me).

We're now looking at seperating our own Nagios and that for the
customers. That way, we'd get the "have N accounts for everybody"
to be a little more manageable. For our internal stuff, we'd go
the route you described (everybody seeing everything). Seeing as
about 90% of what we monitor is our own stuff, that would make
quite a difference.

Regards,
Tobias

[Alex Burger]

Hi Tobias.

I have expanded on the Altinity patch by adding a 'can_submit_commands'
and 'can_submit_commands_strict' option to contact groups. The
limitation of having a can_submit_commands option on the user is that
it's an all or nothing option. A user is either view-only for all
devices, or not.

I will be using can_submit_commands_strict for people who need to be
able to submit commands for the servers and services they manage, but
also be able to only view some other servers and devices. I don't want
the users to be able to view ALL devices.

*can_submit_commands_strict:* You grant users full access to all or
some systems, but want to restrict them from issuing commands for a few
devices.

If a device has multiple contact groups defined and any one of them
denies submit commands with can_submit_commands_strict 0, then the user
is denied even if the user belongs to a group that permits it.

*can_submit_commands:* You grant users read/only access to all systems,
but you want to allow the user to issue commands for a few devices.

With can_submit_commands, if a device has multiple contact groups
defined and any one of them allows submit commands, the user can submit
commands. If there was only one contact group listed and it had
can_submit_commands set to 0, the user would not be able to submit commands.

Is this what you are looking for?

Alex

Post by Tobias Klausmann
Hi!
I've got a problem that I don't how to solve best in Nagios. I
think other people have run into the same problem (I know that
someone has run into a /similar/ problem).
I'm running 2.5 on a mid-sized installations (~300 hosts, ~2500
services). Thing is, our projects/(host|service)groups vary
wildly in who is responsible for them. Unfortunately, all these
projects are also heavily intertwined in their dependencies.
Say we have a web mail project A. This consists of several
web servers, databases and the like. It is heavily dependent on
the LDAP project B and the mail server project C. While B and C
have the same group of admins, project A is managed by an
entirely different group of people.
As such, we have configured Nagios that the group that is
responsible for project can only see the machines of project A and
the "B-and-C-people" can only see B and C.
Everything is peachy.
Except. Sometimes, project A may look like it's broken (pages
time out etc). But in reality, there's a spam attack and the
project B (the LDAP infrastructure) is so slow it simply grinds
to a halt. In this case it would obviously be nice if the people
from project A could see that project B is slow. Yet they should
not be able to change the notification options/acknowledgements
etc etc of projects B or C.
The altinity people have created a patch for the "view some,
change none" scenario[0]. Unfortunately, what I'd need is a
mechanism for the "view some, change a few" scenario I outlined
above.
How do others deal with this kind of problem? I'm sure we're not
the only ones who've run into it.
As of currently, our best guess would be to create
pseudo-accounts (like john.foo and john.foo-admin) and hack the
CGI(s) to only allow the commands from -admin accounts which are
in the notification list (with notification options set to "n").
We already do this to let people see machines they don't
mailed/paged/called about.
Regards,
Tobias
[0] http://altinity.blogs.com/dotorg/2006/02/a_view_some_cha.html

[Tobias Klausmann]

Hi!

Post by Alex Burger
I have expanded on the Altinity patch by adding a 'can_submit_commands'
and 'can_submit_commands_strict' option to contact groups. The
limitation of having a can_submit_commands option on the user is that
it's an all or nothing option. A user is either view-only for all
devices, or not.
I will be using can_submit_commands_strict for people who need to be
able to submit commands for the servers and services they manage, but
also be able to only view some other servers and devices. I don't want
the users to be able to view ALL devices.
*can_submit_commands_strict:* You grant users full access to all or
some systems, but want to restrict them from issuing commands for a few
devices.
If a device has multiple contact groups defined and any one of them
denies submit commands with can_submit_commands_strict 0, then the user
is denied even if the user belongs to a group that permits it.
*can_submit_commands:* You grant users read/only access to all systems,
but you want to allow the user to issue commands for a few devices.
With can_submit_commands, if a device has multiple contact groups
defined and any one of them allows submit commands, the user can submit
commands. If there was only one contact group listed and it had
can_submit_commands set to 0, the user would not be able to submit commands.
Is this what you are looking for?

I'm not quite sure :)

Actually I'm not sure I understand the functionality you added
correctly. I'll explain what I think I've understood:

The new attribute (..._strict) belongs to contact_groups. If it
is set to 1 on a contactgroup, everything behaves as normal.

If it is set to 0, then no user who's associated with a
hostgroup that is also associated with this contactgroup may
issue commands for that particular host(group).

As this sounds more than counter-intuitive, I strongly suspect
I've misunderstood something.

Please enlighten me. :)

Regards,
Tobias

[Ton Voon]

Hi Alex,

This is a really interesting idea. We've recently made a patch to
Nagios so that a contact will only see the services in the CGIs based
on their contact groups - currently Nagios 2.x will show all services
if that contact is a contact for the host (which you would normally
do so they receive host notifications).

Our patch means we use contactgroups to "slice" which services are
visible per contact. I'll be blogging about this soon (when I get a
spare 30 mins!).

However, this still lacks the ability to show some services but only
allow changes to a subset, which is what Tobias is interested in.

I think the "read/write" attribute needs to be associated with the
contact. So this implementation looks more obvious (to me):

define contact {
name person
contactgroups cg1,cg2,cg3 # means can submit commands
contactgroups_viewonly cg5,cg6
}

This would effectively mean the can_submit_commands attribute is
redundant, because you just use contactgroups_viewonly instead of
contactgroups.

Does this make sense?

Ton

Post by Alex Burger
Hi Tobias.
I have expanded on the Altinity patch by adding a
'can_submit_commands'
and 'can_submit_commands_strict' option to contact groups. The
limitation of having a can_submit_commands option on the user is that
it's an all or nothing option. A user is either view-only for all
devices, or not.
I will be using can_submit_commands_strict for people who need to be
able to submit commands for the servers and services they manage, but
also be able to only view some other servers and devices. I don't want
the users to be able to view ALL devices.
*can_submit_commands_strict:* You grant users full access to all or
some systems, but want to restrict them from issuing commands for a few
devices.
If a device has multiple contact groups defined and any one of them
denies submit commands with can_submit_commands_strict 0, then the user
is denied even if the user belongs to a group that permits it.
*can_submit_commands:* You grant users read/only access to all systems,
but you want to allow the user to issue commands for a few devices.
With can_submit_commands, if a device has multiple contact groups
defined and any one of them allows submit commands, the user can submit
commands. If there was only one contact group listed and it had
can_submit_commands set to 0, the user would not be able to submit commands.
Is this what you are looking for?
Alex

Post by Tobias Klausmann
Hi!
I've got a problem that I don't how to solve best in Nagios. I
think other people have run into the same problem (I know that
someone has run into a /similar/ problem).
I'm running 2.5 on a mid-sized installations (~300 hosts, ~2500
services). Thing is, our projects/(host|service)groups vary
wildly in who is responsible for them. Unfortunately, all these
projects are also heavily intertwined in their dependencies.
Say we have a web mail project A. This consists of several
web servers, databases and the like. It is heavily dependent on
the LDAP project B and the mail server project C. While B and C
have the same group of admins, project A is managed by an
entirely different group of people.
As such, we have configured Nagios that the group that is
responsible for project can only see the machines of project A and
the "B-and-C-people" can only see B and C.
Everything is peachy.
Except. Sometimes, project A may look like it's broken (pages
time out etc). But in reality, there's a spam attack and the
project B (the LDAP infrastructure) is so slow it simply grinds
to a halt. In this case it would obviously be nice if the people
from project A could see that project B is slow. Yet they should
not be able to change the notification options/acknowledgements
etc etc of projects B or C.
The altinity people have created a patch for the "view some,
change none" scenario[0]. Unfortunately, what I'd need is a
mechanism for the "view some, change a few" scenario I outlined
above.
How do others deal with this kind of problem? I'm sure we're not
the only ones who've run into it.
As of currently, our best guess would be to create
pseudo-accounts (like john.foo and john.foo-admin) and hack the
CGI(s) to only allow the commands from -admin accounts which are
in the notification list (with notification options set to "n").
We already do this to let people see machines they don't
mailed/paged/called about.
Regards,
Tobias
[0] http://altinity.blogs.com/dotorg/2006/02/a_view_some_cha.html

----------------------------------------------------------------------
---
Using Tomcat but need to do more? Need to support web services,
security?
Get stuff done quickly with pre-integrated technology to make your
job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
http://sel.as-us.falkag.net/sel?
cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Nagios-users mailing list
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when
reporting any issue.
::: Messages without supporting info will risk being sent to /dev/null
This message has been scanned for viruses by MailController -
www.MailController.altohiway.com

http://www.altinity.com
T: [phone]
F: [phone]
Skype: tonvoon

[Alex Burger]

Hi Ton.

Post by Ton Voon
Hi Alex,
I think the "read/write" attribute needs to be associated with the
define contact {
name person
contactgroups cg1,cg2,cg3 # means can submit commands
contactgroups_viewonly cg5,cg6
}
This would effectively mean the can_submit_commands attribute is
redundant, because you just use contactgroups_viewonly instead of
contactgroups.

The more I think about it, the more I think we are looking at this the
wrong way. With file system or application permissions, we would assign
a group to a folder/object, and then pick what rights the group would
have. Why don't we do the same thing with Nagios?

Leave the groups as they are, but modify the host and service
contact_groups command? For example:

define host{
host_name localhost
contact_groups netops:rw, helpdesk:r
}

For backwards compatibility, if no permissions are set, the defaults
would be rw so the following would be the same:

define host{
host_name localhost
contact_groups netops, helpdesk:r
}

If a user was in both the netops and helpdesk group, the user should
have rw access.

This will take a bit more work to implement, but I think it makes more
sense. What do you think?

Alex

[Alex Burger]

Post by Alex Burger
The more I think about it, the more I think we are looking at this the
wrong way. With file system or application permissions, we would assign
a group to a folder/object, and then pick what rights the group would
have. Why don't we do the same thing with Nagios?
Leave the groups as they are, but modify the host and service
define host{
host_name localhost
contact_groups netops:rw, helpdesk:r
}
For backwards compatibility, if no permissions are set, the defaults
define host{
host_name localhost
contact_groups netops, helpdesk:r
}
If a user was in both the netops and helpdesk group, the user should
have rw access.
This will take a bit more work to implement, but I think it makes more
sense. What do you think?
Alex

Attached is a patch for 2.5 that implements what I described above. It
works on both hosts and services.

The following four lines are are examples of read/write access for
netops and helpdesk:

contact_groups netops, helpdesk
contact_groups netops, helpdesk:rw
contact_groups netops:rw, helpdesk
contact_groups netops:rw, helpdesk:rw

The following two lines are are examples of read/write access for netops
and read only (view only) for helpdesk:

contact_groups netops, helpdesk:r
contact_groups netops:rw, helpdesk:r

Alex

[Ton Voon]

Post by Alex Burger

Post by Ton Voon
Hi Alex,
I think the "read/write" attribute needs to be associated with the
define contact {
name person
contactgroups cg1,cg2,cg3 # means can submit commands
contactgroups_viewonly cg5,cg6
}
This would effectively mean the can_submit_commands attribute is
redundant, because you just use contactgroups_viewonly instead of
contactgroups.

The more I think about it, the more I think we are looking at this
the wrong way. With file system or application permissions, we
would assign a group to a folder/object, and then pick what rights
the group would have. Why don't we do the same thing with Nagios?
Leave the groups as they are, but modify the host and service
define host{
host_name localhost
contact_groups netops:rw, helpdesk:r
}
For backwards compatibility, if no permissions are set, the
define host{
host_name localhost
contact_groups netops, helpdesk:r
}
If a user was in both the netops and helpdesk group, the user
should have rw access.
This will take a bit more work to implement, but I think it makes
more sense. What do you think?

Firstly, this is fantastic work, Alex. Nice to see someone run with
an idea.

I've been mulling this over the weekend and I think you're right: I
was looking at this the wrong way. It was very smart of you to make
the analogy with filesystem security and I think you have the right
design.

Authorization is about defining a user's permissions on an object
(http://en.wikipedia.org/wiki/Access_control#Authorization). The base
objects in Nagios are the host and service object. These objects
should then hold information about which users (contacts) are allowed
which permission. You've got a good thread on what the permissions
should be, so I'll ignore that. But the assigning of permissions at
the host/service definition is, I think, the right way to go.

My only request is to add in the ability to check for a single
contact too. This will be more important in Nagios 3 as Ethan has
said you will be allowed to specify single contacts from a host/
service definition, without the need for contactgroups.

When you have your patch applied, I will request removal of the
can_submit_commands patch as this is just a fudge from the
sophisticated security model you will have added in (my patch is
analogous to setting a user to "/bin/false" for their shell, I guess).

Ton

http://www.altinity.com
T: [phone]
F: [phone]
Skype: tonvoon

[Hari Sekhon]

This is a very interesting thread, especially since I am currently
wondering how I can do this sort of thing. I want to give a web
interface to consultants to view our web site availability. I have
created a user and contactgroup which shows only the services I have
added the group to. The problem is that even this limited account can
switch off checks or notifications and I can't see a way to stop this.

It appears that when this account switches off a notification, this is
done on a global basis which is bad. I'm using nagios 1.4.1.

Reading through this thread it appears that the issue is under debate at
the moment. Does this mean that what I want, a read only user cannot be
done at the moment?

-h

Hari Sekhon

Post by Alex Burger

Post by Ton Voon
Hi Alex,
I think the "read/write" attribute needs to be associated with the
define contact {
name person
contactgroups cg1,cg2,cg3 # means can submit commands
contactgroups_viewonly cg5,cg6
}
This would effectively mean the can_submit_commands attribute is
redundant, because you just use contactgroups_viewonly instead of
contactgroups.

The more I think about it, the more I think we are looking at this
the wrong way. With file system or application permissions, we would
assign a group to a folder/object, and then pick what rights the
group would have. Why don't we do the same thing with Nagios?
Leave the groups as they are, but modify the host and service
define host{
host_name localhost
contact_groups netops:rw, helpdesk:r
}
For backwards compatibility, if no permissions are set, the defaults
define host{
host_name localhost
contact_groups netops, helpdesk:r
}
If a user was in both the netops and helpdesk group, the user should
have rw access.
This will take a bit more work to implement, but I think it makes
more sense. What do you think?

Firstly, this is fantastic work, Alex. Nice to see someone run with an
idea.
I've been mulling this over the weekend and I think you're right: I
was looking at this the wrong way. It was very smart of you to make
the analogy with filesystem security and I think you have the right
design.
Authorization is about defining a user's permissions on an object
(http://en.wikipedia.org/wiki/Access_control#Authorization). The base
objects in Nagios are the host and service object. These objects
should then hold information about which users (contacts) are allowed
which permission. You've got a good thread on what the permissions
should be, so I'll ignore that. But the assigning of permissions at
the host/service definition is, I think, the right way to go.
My only request is to add in the ability to check for a single contact
too. This will be more important in Nagios 3 as Ethan has said you
will be allowed to specify single contacts from a host/service
definition, without the need for contactgroups.
When you have your patch applied, I will request removal of the
can_submit_commands patch as this is just a fudge from the
sophisticated security model you will have added in (my patch is
analogous to setting a user to "/bin/false" for their shell, I guess).
Ton
http://www.altinity.com
T: [phone]
F: [phone]
Skype: tonvoon
------------------------------------------------------------------------
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
------------------------------------------------------------------------
_______________________________________________
Nagios-users mailing list
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue.
::: Messages without supporting info will risk being sent to /dev/null

[Ton Voon]

Post by Hari Sekhon
This is a very interesting thread, especially since I am currently
wondering how I can do this sort of thing. I want to give a web
interface to consultants to view our web site availability. I have
created a user and contactgroup which shows only the services I
have added the group to. The problem is that even this limited
account can switch off checks or notifications and I can't see a
way to stop this.

You can either use the "view some, change none" patch that we did:
http://altinity.blogs.com/dotorg/2006/02/a_view_some_cha.html

or the earlier patch in this thread from Alex with his new
contactgroups permissions.

Ton

http://www.altinity.com
T: [phone]
F: [phone]
Skype: tonvoon

[Alex Burger]

Hi Ton.

My only request is to add in the ability to check for a single contact
too. This will be more important in Nagios 3 as Ethan has said you will
be allowed to specify single contacts from a host/service definition,
without the need for contactgroups.

I haven't tried Nagios 3 yet, but it doesn't look like my patch will
work with it. I'll see if I can port it over. Any idea when the
release date is for v3?

Thanks

Alex

[Ton Voon]

Post by Alex Burger
I haven't tried Nagios 3 yet, but it doesn't look like my patch will
work with it. I'll see if I can port it over. Any idea when the
release date is for v3?

Ethan stated at the Nagios Conference that he was aiming for v3 to go
stable by end of this year.

Ton

http://www.altinity.com
T: [phone]
F: [phone]
Skype: tonvoon

[Alex Burger]

Hi Ton.

Post by Ton Voon

Post by Alex Burger
I haven't tried Nagios 3 yet, but it doesn't look like my patch will
work with it. I'll see if I can port it over. Any idea when the
release date is for v3?

Ethan stated at the Nagios Conference that he was aiming for v3 to go
stable by end of this year.

I was able to port the patch to Nagios 3.0 so hopefully there is enough
time to consider it for the final release. I have submitted patches for
both 2.5 and 3.0 to the Nagios-Devel list. This version also adds
permissions to the escalation checks.

Alex

[Steve Shipway]

Post by Alex Burger
Leave the groups as they are, but modify the host and service
define host{
host_name localhost
contact_groups netops:rw, helpdesk:r
}
For backwards compatibility, if no permissions are set, the defaults
define host{
host_name localhost
contact_groups netops, helpdesk:r
}
If a user was in both the netops and helpdesk group, the user should
have rw access.

This is exactly what we need, and the best way I have seen (so far) to
implement it. In particular it has backwards compatibility and does
not involve an additional directive. Much simpler to do it via groups
rather than at a per-user level, and much more maintainable.

This is the way I'd like to see it implemented in the official tree,
maybe with a nagios.cfg option to allow you to set the default to be :rw
or :r (so that once you've fully implemented things you can change
default to be :r, best to default to the lower level)

Steve

--
Steve Shipway
ITSS, University of Auckland
[phone] x 86487
***@auckland.ac.nz

[Hugo van der Kooij]

Post by Steve Shipway

Post by Alex Burger
Leave the groups as they are, but modify the host and service
define host{
host_name localhost
contact_groups netops:rw, helpdesk:r
}
For backwards compatibility, if no permissions are set, the defaults
define host{
host_name localhost
contact_groups netops, helpdesk:r
}
If a user was in both the netops and helpdesk group, the user should
have rw access.

This is exactly what we need, and the best way I have seen (so far) to
implement it. In particular it has backwards compatibility and does
not involve an additional directive. Much simpler to do it via groups
rather than at a per-user level, and much more maintainable.
This is the way I'd like to see it implemented in the official tree,
maybe with a nagios.cfg option to allow you to set the default to be :rw
or :r (so that once you've fully implemented things you can change
default to be :r, best to default to the lower level)

To remain in the traditional unix style. How about an eXecute flag?

In this contact it would best be written as Notify flag instead.

So I can have 1 group as nrw (the engineers on call), customer on nr,
helpdesk on r.

Hugo.

[Alex Burger]

Post by Hugo van der Kooij

Post by Alex Burger
Leave the groups as they are, but modify the host and service
define host{
host_name localhost
contact_groups netops:rw, helpdesk:r
}
For backwards compatibility, if no permissions are set, the defaults
define host{
host_name localhost
contact_groups netops, helpdesk:r
}

To remain in the traditional unix style. How about an eXecute flag?
In this contact it would best be written as Notify flag instead.
So I can have 1 group as nrw (the engineers on call), customer on nr,
helpdesk on r.

How about:

r: View in web interface

x: Submit commands for this host/service

w: Not really needed yet. Maybe some of the other programs that allow
you to modify the configuration files could use w to allow a user to
modify the host / service.

n: Notify if contact has a pager or email defined

I also changed it so that you will only see a service if you are a
contact for it. I think this is the same change that Ton mentioned in
his last email. I did this to test the 'r' permission.

For backwards compatibility, the default would be rwxn.

So, the engineers would have: nrx, customer: nr and helpdesk r.

Attached is an updated patch.

Alex

[Tobias Klausmann]

Hi!

First off: thanks for all your work, it didn't quite expect so
much (and such constructive/worthwile) feedback.

Post by Alex Burger
r: View in web interface
x: Submit commands for this host/service
w: Not really needed yet. Maybe some of the other programs that allow
you to modify the configuration files could use w to allow a user to
modify the host / service.
n: Notify if contact has a pager or email defined

I think one could make a case for x being everything that
concerns the current state of an object, i.e. mainly
acknowledgement(s). The w flag could be used for en/disabling
(semi)permanent stuff, like disabling active checks.

On the other hand, many actions (like schedule downtime) would
fall into a grey area, so maybe using x for all of them and
"keeping" w for later is better.

Post by Alex Burger
I also changed it so that you will only see a service if you are a
contact for it. I think this is the same change that Ton mentioned in
his last email. I did this to test the 'r' permission.

This was the default in our installation (by way of not having an
asterisk in the corresponding line(s) in the main config file.

Post by Alex Burger
For backwards compatibility, the default would be rwxn.
So, the engineers would have: nrx, customer: nr and helpdesk r.
Attached is an updated patch.

I'll try to get a peek at it this week.

Thanks, again (all of you).

Regards,
Tobias

[Alex Burger]

Hi Tobias.

Post by Tobias Klausmann
I think one could make a case for x being everything that
concerns the current state of an object, i.e. mainly
acknowledgement(s). The w flag could be used for en/disabling
(semi)permanent stuff, like disabling active checks.
On the other hand, many actions (like schedule downtime) would
fall into a grey area, so maybe using x for all of them and
"keeping" w for later is better.

Right now, all commands that can be submitted are grouped together. I
don't think there is currently any way to to allow someone to schedule
downtime, but not force a check of all services. This of course could
be changed, but I haven't looked at it yet.

To implement this, we would need a list of all the possible service /
host commands, and what permission a user should have to execute it. I
had a quick look and it looks like most should require a 'wx' permission
except for maybe 'schedule an imemdiate check of all services'. I don't
like the idea of giving 're-schedule the next check of this service' to
anyone with read access as they could set it to check a week from now.
Like you said, maybe it's better to just keep the 'x' as it is.

Post by Tobias Klausmann

Post by Alex Burger
I also changed it so that you will only see a service if you are a
contact for it. I think this is the same change that Ton mentioned in
his last email. I did this to test the 'r' permission.

This was the default in our installation (by way of not having an
asterisk in the corresponding line(s) in the main config file.

It looks like if you are a contact for a host, then you automatically
have access to view all services. I tested this by making a user
(group) a contact for a host and only two of the host's services. The
user was able to see all services even though he was not listed on the
others.

Alex

[Tobias Klausmann]

Hi!

Post by Tobias Klausmann

Post by Alex Burger
For backwards compatibility, the default would be rwxn.
So, the engineers would have: nrx, customer: nr and helpdesk r.
Attached is an updated patch.

I'll try to get a peek at it this week.

Well, it took a little longer due to other things acting up
elsewhere.

As far as I can tell, it works perfectly - except...

We use NagiosGrapher to turn the perfdata into nice little colorful
thingies for the app developers. Unfortunately, NG seems to not
work well with the patch: It thinks "foo:r" is the group of the
same name, not the group "foo".

This will probably be easy to fix in a generic way (i.e. drop
everything after the last ":") and a little more complicated if
the perms should be parsed (though I have no idea what perms
would be needed for the graph: n or x only would prevent the user
to see the host/service (and thus the extinfo link) in the first
place. And preventing "r" users from seeing the graphs doesn't
make much sense, IMO).

Thus, I'll probably patch NG to just ignore the perms.

I'll post the patch here (if it's not too ugly ;))

Post by Tobias Klausmann
Thanks, again (all of you).

I can only re-iterate that.

Regards,
Tobias

[Tobias Klausmann]

Hi!

Post by Tobias Klausmann
Thus, I'll probably patch NG to just ignore the perms.
I'll post the patch here (if it's not too ugly ;))

See the attached file. Have fun.

Regards,
Tobias

[Alex Burger]

Post by Alex Burger
r: View in web interface
x: Submit commands for this host/service
w: Not really needed yet. Maybe some of the other programs that allow
you to modify the configuration files could use w to allow a user to
modify the host / service.
n: Notify if contact has a pager or email defined
I also changed it so that you will only see a service if you are a
contact for it. I think this is the same change that Ton mentioned in
his last email. I did this to test the 'r' permission.
For backwards compatibility, the default would be rwxn.

Attached is an updated patch that adds a 'default_permissions' option to
nagios.cfg and cgi.cfg that Steve Shipway suggested. From
sample-config/cgi.cfg.in:

# DEFAULT HOST/SERVICE PERMISSIONS
# This option contains a list of default permissions for hosts and
# services that will be used when permissions are not explicitly
# set on a host or service. When not defined, the default is all
# permissions (rwxn). Note: This option must be set the same in
# both cgi.cfg and nagios.cfg.

#default_permissions=rwxn

As you can see, the option needs to be in both config files although I
would prefer to have it only in nagios.cfg. It is needed in nagios.cfg
for base/notifications.c which has nothing to do with the cgi. If
someone knows how to combine the two, please let me know, but I suspect
that the cgi and main nagios programs are completely separate from each
other.

If anyone can do some testing I would appreciate it.

Alex