Re: [Ganglia-developers] Web 2.0 UI code freeze
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 ? Vladimir On Sun, 10 Apr 2011, Alex Dean wrote: On Apr 6, 2011, at 1:34 PM, Bernard Li wrote: Hi all: On Wed, Apr 6, 2011 at 11:14 AM, Vladimir Vuksan vli...@veus.hr wrote: I spoke to Bernard and we are considering doing a code freeze of the Web 2.0 UI. I'd like to release it by the end of month so that people can start using it. Yeah, let's try to get this out soon. From the TODO https://sourceforge.net/apps/trac/ganglia/browser/branches/monitor-web-2.0/TODO, I'd like to get the following done before the code freeze: - Add back the Ganglia logo - Provide an easy method for user to add their organization's logo In my opinion, the new UI features which write to the file system on the web server (to save view definitions, etc) should require some kind of authentication. Allowing any random user to change the UI's configuration seems like a hole we should fill before releasing. Does anyone use the 'private clusters' feature which is implemented in auth.php? Seems like we could use this authentication mechanism, though I did have a few concerns. - The authentication database is a 'private_clusters' text file, stored in the same directory as auth.php. That means I could take a look at http://site.com/ganglia/private_clusters via my web browser and download the whole list of cluster names MD5 hashes. - I'm not a crypto guy, but I believe the MD5 algorithm is now widely considered to be insecure, and not something we should be relying on. http://en.wikipedia.org/wiki/MD5#Security Before release, I suggest we: - Move the private_clusters file outside Apache's DocumentRoot. Maybe @sysconfdir@/private_clusters? - Update auth.php to use a more secure (but still widely available) hashing algorithm. SHA1 or otherwise? - Require authentication for actions which can change UI configuration, like creating/altering views, or for any other action which might write user data to the web server's filesystem. - Support a wildcard cluster name in private_clusters, or a 'root' user, so an admin would only need to define 1 password to be able to edit anything in any cluster. Maybe that's what the 'control' context is for? alex -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers -- 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
Re: [Ganglia-developers] Web 2.0 UI code freeze
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
Re: [Ganglia-developers] Web 2.0 UI code freeze
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
