[
https://issues.apache.org/jira/browse/MAPREDUCE-3231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13140060#comment-13140060
]
Luke Lu commented on MAPREDUCE-3231:
------------------------------------
bq. so I don't think it is that big of a deal.
Bobby, you're seriously underestimate the potential of MRv2. The number of
enterprise applications (which means they have nice UIs) that can be ported to
MR2 is orders of magnitude more than listed. People should worry more about
using the container APIs than porting the UIs.
Again, I'd like to call your attention to the *fundamental wrongness* of your
approach as you fail/refuse to see it. The most common use case of AM UI is for
application users themselves, which is more than 99% of the cluster users.
You're trying to force people to adopt a special way, and in a sense, raising
the taxes of the 99% for the sake of 1% (the self entitlement permeates
throughout your arguments). Sorry to use a cliché but I was a 1% and I support
the 99% :)
bq. So Wiki/Twiki are a bad idea? Because aren't they a trusted front-end with
a special interpreter for a special scheme?
I can't speak for other wikis, but mediawiki (the one that powers wikipedia)
had/has so many security bugs that I lost count. Many of the bugs are, not
surprisingly, in the template interpreter and related code.
bq. because I would never go to Wikipedia if I thought I could easily get a
virus from it.
This is a classic example of false sense of security through ignorance. You can
get a virus from wikipedia, even if javascript is turned off, especially if you
use a common combination of browsers/operating systems versions. I don't think
you're not paranoid enough to write secure code yet :)
bq. Didn't you say that you don't trust Caja. Why then didn't we go with a
different library?
I don't trust Caja yet but its security track record is way better than
mediawiki. The main issue of Caja is that it's currently too slow
(multi-pass/stage compiler) for non-trivial pages and that it doesn't have an
official release yet. The other solutions I mentioned are not surprisingly
existing proxy solutions. I was actually thinking about creating a simple
plugin interface to allow people to delegate to deployment chosen solution for
common web security, when the request is not the owner of AM.
bq. I have seen very very old version of pig that are no longer supported being
run because there is no motivation to fix it.
I'm not sure if you're intentionally trying to conflate the issues here. I was
talking about the difficulties of writing *trusted* *webapps*. The example you
gave is neither and very much off topic. The main thrust of my original design
is that a simple proxy can obviate the need to write complex (bug prone)
trusted webapps in our particular use cases.
OTOH, I do see your perspective as an on-call dev, as I've been there as well.
Users are always trying to minimize their own work and avoiding upgrade if
things are working for them. That's life and being a control freak doesn't
really help here. You should focus your energy to fix the framework with
reasonable security and limits and let users work within the limits.
> Improve Application Master And Job History UI Security
> ------------------------------------------------------
>
> Key: MAPREDUCE-3231
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-3231
> Project: Hadoop Map/Reduce
> Issue Type: Improvement
> Components: mrv2
> Affects Versions: 0.23.0
> Reporter: Robert Joseph Evans
> Assignee: Robert Joseph Evans
> Attachments: AMWebSecurityProposal.pdf
>
>
> I propose a stripped down JSON based protocol for creating safe user generate
> web pages. This JIRA is intended first of all as a place for a discussion
> about this proposal, and then if there are no serious objections this will be
> an Umbrella JIRA to implement the changes proposed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
