[
https://issues.apache.org/jira/browse/HADOOP-2230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543716
]
Allen Wittenauer commented on HADOOP-2230:
------------------------------------------
There are a lot of hidden issues here. Let's see if I can cover them all in
one post. :)
- On role based/capable operating systems (Solaris comes to mind) it is
possible to strictly curtail root's capability. It is not a safe assumption to
assume that root==all powerful.
- In many cases, esp. for large data centers, the sysadmins are not the same
people who administer the applications. So trusting a group like wheel or root
to hold who should have the power in Hadoop would cause these types of places a
lot of pain.
- Trusting the uid that hadoop to be running under as privileged may not be
possible if the hadoop process is running under a dedicated, noaccess type of
account. [In many places, they incorrectly use nobody or daemon for this type
of thing, but the name of the account is irrelevant. ]
That said, I think I'd really prefer to either be able to specify exactly what
users or what groups should contain the users that should be privileged.
While I realize there is no 'su' capability either, the more I think about
this, the more I'm thinking that there probably should be some sort of 'double
check' when it comes time for privilege escalation. After all, if I'm an admin
user I don't want to accidently rm -rf / without having some sort of safety net
(other than Trash, of cousre). chown/chgrp are much more dangerous without
this safety net, I think. For example, under roles on Solaris, a user can use
their 'superpowers' by issuing 'pfexec command' (vs. just using 'command').
Hmm...
> Post users: need admin-only access to HDFS
> -------------------------------------------
>
> Key: HADOOP-2230
> URL: https://issues.apache.org/jira/browse/HADOOP-2230
> Project: Hadoop
> Issue Type: New Feature
> Environment: All
> Reporter: Allen Wittenauer
>
> When user support gets added to HDFS, administrators are going to need to be
> able to set the namenode such that it only allows connections/interactions
> from the administrative user. This is particularly important after upgrades
> and for other administrative work that may require the changing of user/group
> ownership, permissions, location of files within the HDFS, etc.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
