[
https://issues.apache.org/jira/browse/SPARK-18551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15703410#comment-15703410
]
Marcelo Vanzin edited comment on SPARK-18551 at 11/28/16 10:58 PM:
-------------------------------------------------------------------
I'll ignore unsecured services here; as SteveL mentions, it's trivial to do
whatever you want if HDFS is not secured.
bq. For your first point, my thinking was that the person who started the SHS
and enabled the deletion config would be the liable user.
That's how your change works. But more often than not, the service will be
running as some system user (e.g. "spark") and not as the user who started the
service (more often than not some admin). Documenting is the bare minimum, but
really when exposing this kind of functionality I expect at least some security
to exist around it.
bq. I'm not quite sure what you mean about the UI's auth code though
If user "alice" runs an application, user "bob" should not be able to delete
its logs. That works in HDFS because the directory where the logs are stored
has the sticky bit set, and "bob" cannot write to "alice"'s logs. So "bob"
cannot delete "alice"'s logs either.
But here, without applying the ACLs the application has set up to this feature,
you would be allowing that scenario. Yes, I'm talking about the security
manager, but it only exists at the application level currently; if you look at
its config, it has a bunch of ACL-related configs which are only enforced by
the Spark UI (and not by the parent UI of the history server).
bq. The user here has no access to the log folder without going through their
admin.
My feeling about that is that the admin is creating the problem and it's not
for the SHS to fix it by creating a bunch of other problems. The user needs
access to the file system to write the logs in the first place, so he should
have access to the file system to delete the logs if he wants to.
I currently think this feature brings more issues than it solves, but you can
try to convince me otherwise. At the very, very least it should be disabled by
default, which makes it less useful from the get go...
was (Author: vanzin):
I'll ignore unsecured services here; as SteveL mentions, it's trivial to do
whatever you want if HDFS is not secured.
bq. For your first point, my thinking was that the person who started the SHS
and enabled the deletion config would be the liable user.
That's how your change works. But more often than not, the service will be
running as some system user (e.g. "spark") and not as the user who started the
service (more often than not some admin). Documenting is the bare minimum, but
really when exposing this kind of functionality I expect at least some security
to exist around it.
bq. I'm not quite sure what you mean about the UI's auth code though
If user "alice" runs an application, user "bob" should not be able to delete
its logs. That works in HDFS because the directory where the logs are stored
has the sticky bit set, and "bob" cannot write to "alice"'s logs. So "bob"
cannot delete "alice"'s logs either.
But here, without application the ACLs the application has set up to this
feature, you would be allowing that scenario. Yes, I'm talking about the
security manager, but it only exists at the application level currently; if you
look at its config, it has a bunch of ACL-related configs which are only
enforced by the Spark UI (and not by the parent UI of the history server).
bq. The user here has no access to the log folder without going through their
admin.
My feeling about that is that the admin is creating the problem and it's not
for the SHS to fix it by creating a bunch of other problems. The user needs
access to the file system to write the logs in the first place, so he should
have access to the file system to delete the logs if he wants to.
I currently think this feature brings more issues than it solves, but you can
try to convince me otherwise. At the very, very least it should be disabled by
default, which makes it less useful from the get go...
> Add functionality to delete event logs from the History Server UI
> -----------------------------------------------------------------
>
> Key: SPARK-18551
> URL: https://issues.apache.org/jira/browse/SPARK-18551
> Project: Spark
> Issue Type: New Feature
> Components: Spark Core, Web UI
> Reporter: Alex Bozarth
>
> Sometimes a Spark user will only have access to a History Server to interact
> with their (past) applications. But without access to the server they can
> only delete applications through use of the FS Cleaner feature, which itself
> can only clean logs older than a set date.
> I propose adding the ability to delete specific applications via the History
> Server UI with the default setting to off.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
