Advanced permissions/user properties

[Ton Voon]

On 4 Nov 2006, at 16:43, Alex Burger wrote:

> Ton Voon wrote:
>> Hi Alex,
>> 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.
>
> 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?

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: +44 (0)870 787 9243
F: +44 (0)845 280 1725
Skype: tonvoon



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/users/attachments/20061106/bee5591f/attachment.html>
-------------- next part --------------
-------------------------------------------------------------------------
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
-------------- next part --------------
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
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