I think that we should punt authentication to other systems/modules
that are dedicated to doing so. Apache (et al) have lots of ways of
handling authentication, and I don't see *any* reason to reinvent the
wheel here, and a lot of reasons not to.
If we want to provide hooks to allow for access based on a username,
that's fine ("if (valid_auth(user) and (user in lis)t) { display
chart}" sort of thing). This is even a useful trick, and could be
extended to groups (from /etc/group, AD, NIS, etc), if we so choose.
But punt the authentication stuff to something else entirely.
If a user wants to store custom views and such, push it into a cookie,
and store it on the browser side. Under *NO* circumstances should we
allow a user to write data to the server through Ganglia. Having a
"canned" view, created by the admin, stored in a config file on the
webserver is okay, so long as it is not possible to edit the file
through the web pages.
On Mon, Apr 11, 2011 at 22:38, Alex Dean <a...@crackpot.org> wrote:
>
> On Apr 11, 2011, at 9:07 PM, Vladimir Vuksan wrote:
>
>> I am not sure what the right approach is. We could provide optional
>> authentication but this may be better addressed by people implementing
>> access controls in Apache ie. adding Basic auth to particular URLs. You
>> could certainly easily "disable" writing by setting proper permissions on
>> conf/ directory. This may be a non-issue for lots of people who are behind
>> firewalls and do not want an extra level of authentication. Perhaps we
>> should just document some of these approaches instead of reinventing the
>> authentication.
>>
>> Thoughts ?
>
> I agree about not wanting to overly complicate things.
>
> If we had some is_writable() checks, and didn't display links to actions
> which required write access (like updating a view) when that access wasn't
> available, that would probably be enough to implement a basic level of
> security. It seems a little clunky to have to chmod the filesystem, make
> some changes, and chmod it back, but it may be good enough for now. If we go
> that route, I think our Makefile ought to set the conf/ directory as
> read-only by default.
>
> I like the idea of using Apache's authentication mechanisms, but they may not
> be fine-grained enough in some cases. For example, view.php is used both to
> display a view and to modify it. How would you make it read-only for some
> users, but allow admins to edit views? You might be able to use a
> LocationMatch directive, but that seems likely to become a mess in a hurry.
>
> I think it would be pretty straightforward to take the concept already in
> auth.php, and add a distinction between 'view' (for private clusters) and
> 'edit' (for actions which change config) permissions. Collecting username &
> password from the user could still be done via HTTP auth as is already done
> in auth.php, but you'd need to change the file to distinguish between those
> who can edit and those who can view.
>
> This doesn't feel overly complex to me, but I'm interested in what others
> have to say. I don't want to hold up a release if I'm the only one who's
> concerned. Any other opinions out there?
>
> alex
> ------------------------------------------------------------------------------
> Forrester Wave Report - Recovery time is now measured in hours and minutes
> not days. Key insights are discussed in the 2010 Forrester Wave Report as
> part of an in-depth evaluation of disaster recovery service providers.
> Forrester found the best-in-class provider in terms of services and vision.
> Read this report now! http://p.sf.net/sfu/ibm-webcastpromo
> _______________________________________________
> Ganglia-developers mailing list
> Ganglia-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ganglia-developers
>
--
Jesse Becker
------------------------------------------------------------------------------
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now! http://p.sf.net/sfu/ibm-webcastpromo
_______________________________________________
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
