hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kurtis Heimerl (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-1298) adding user info to file
Date Thu, 24 May 2007 22:23:16 GMT

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

Kurtis Heimerl commented on HADOOP-1298:

1) I don't think so. This seperates the coded default from the config default. Were I to make
this change, we would simply be moving it from a constant elsewhere to a constant in that
method declaration. I think that the constant is clearer and easier to find as it is. 

2) The idea is to allow users to use these to generate permissions or check permissions. So,
any arbitrary class should be able to access them, as long as they are final. For instance,
this class is currently subclasses by a class outside of it's package. 

3) I agree. This has been fixed. 

4) Fixed

5) Exactly. I'll look them over to see if there's a chance of a leak. 

6) Fixed

7) Three should be all we need. In fact, the methods I implemented do not use the third field.
The only method that does is the logCreateFile because it already has two lists and had no
room for the permissions in the object. Assuming permissions contain file creation and such,
there should be no need to expand this method any further for new features. 

8) Fixed

9) It is related to my issue. In adding new methods, i was told to avoid using UTF8s as they
are deprecated. So, I had to write a new method to get the path from a string, rather than
A UTF8. I could have left the existing getPath and jsut added the new getStringPath, but that
seemed more confusing. I can revert it if you like, but I think the change is a good idea.

10) Root is a problem right now. See 12.

11) What sorts of default values should we have in build.xml?

12) Access control is not in this version. I wanted to implement permissions, and then once
that was settled implement the access control. I think that it shouldn't be difficult. This
created some slight problems though, mostly dealing with root. Root is an access control idea
and not a permissions idea. So root does not exist in this system, except in some strange
areas. Either way, i've added a constant root for everyone to use in Permissions. 

13) The inheriting of permissions from parents would be really easy to implement. Currently
every new file gets their permissions from default. I like the idea of inhereting from parents
and would like to see it implemented in the next iteration of this. Why don't you like it?

> 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.patch13,
hadoop-user-munncha.patch14, hadoop-user-munncha.patch15, hadoop-user-munncha.patch16, hadoop-user-munncha.patch4,
hadoop-user-munncha.patch5, hadoop-user-munncha.patch6, hadoop-user-munncha.patch7, hadoop-user-munncha.patch8,
> 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.

View raw message