Mailing-List: contact hadoop-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hadoop-dev@lucene.apache.org
Message-ID: <32160257.1180045396408.JavaMail.jira@brutus>
Date: Thu, 24 May 2007 15:23:16 -0700 (PDT)
From: "Kurtis Heimerl (JIRA)" <jira@apache.org>
To: hadoop-dev@lucene.apache.org
Subject: [jira] Commented: (HADOOP-1298) adding user info to file
In-Reply-To: <19079061.1177545795510.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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, 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.