hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Cutting (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-1298) adding user info to file
Date Wed, 09 May 2007 20:53:15 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494569
] 

Doug Cutting commented on HADOOP-1298:
--------------------------------------

1. In the FileStatus constructor, the int should not be processed as a decimal integer, but
rather as octal/binary.  So, one would grant all permissions by passing 0777.  I would prefer
the integer alone is stored in FileStatus, rather than six boolean fields, with accessor methods
that AND constants, as described on 3 May above.  These constants should be public so that
others may use them to OR together permission values.

2. There are spurious changes in, e.g., FileSystem.java.  These slow patch review and should
be removed.  (You've inserted a space in one place, some commented code in another, made whitespace
changes in others, etc.)

3. FileSystem.getFileStatus() doesn't have javadoc.

4. We shouldn't use RMI's ServerException, but rather simply IOException.

5. The javadoc for FileSystem.chmod()'s permission parameter should reference FileStatus.

6. FileSystem.getUserName() lacks javadoc.  Also, why is this looking at "test.user.name"?
 That should be removed.

7.  HDFS's Permission.java should, as much as possible, share logic with FileStatus rather
than duplicate it.

8. Both Permissions and DFSFileInfo have owner and ownerGroup fields.  Shouldn't these just
be in one place or the other?  I'd vote for just having these in DFSFileInfo.  In fact, DFSFileInfo
should extend FileStatus, so that these fields (and others) are inherited.  Is there a reason
we can't do that?

9. Since what will remain in Permissions.java functions as a user & group database, it
should be renamed Users.java.  The database should not be static.  Rather, the namenode should
keep an instance for its configuration.  It should be possible, e.g., to run two namenodes
in a single JVM with different user databases.

> adding user info to file
> ------------------------
>
>                 Key: HADOOP-1298
>                 URL: https://issues.apache.org/jira/browse/HADOOP-1298
>             Project: Hadoop
>          Issue Type: New Feature
>          Components: dfs, fs
>            Reporter: Kurtis Heimerl
>         Attachments: hadoop-user-munncha.patch, hadoop-user-munncha.patch, hadoop-user-munncha.patch,
hadoop-user-munncha.patch10, hadoop-user-munncha.patch11, hadoop-user-munncha.patch12, hadoop-user-munncha.patch4,
hadoop-user-munncha.patch5, hadoop-user-munncha.patch6, hadoop-user-munncha.patch7, hadoop-user-munncha.patch8,
hadoop-user-munncha.patch9
>
>
> I'm working on adding a permissions model to hadoop's DFS. The first step is this change,
which associates user info with files. Following this I'll assoicate permissions info, then
block methods based on that user info, then authorization of the user info. 
> So, right now i've implemented adding user info to files. I'm looking for feedback before
I clean this up and make it offical. 
> I wasn't sure what release, i'm working off trunk. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message