[
https://issues.apache.org/jira/browse/HADOOP-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493547
]
Kurtis Heimerl commented on HADOOP-1298:
----------------------------------------
I like point 1. I'll change that once we figure out point two. it might be
meaningful to deprecate the existing length, is directory and stuff.
Also, I reverted change 7 from the previous list. I've decided retuning null
makes more sense. File permissions at this layer are entirely client side. The
server contains no file permissions so returning some would be faulty. The
permissions at this layer are not going to be used to for access control
anyhow.
As far as point two, I agree that the existing design isn't right. It's very
error prone, moreso if I add more fields as per 1.
These solutions bother me as being too closely tied to DFS. The fact that the
client and server contain almost identical data structures indicates too much
coupling. It would be difficult to implement another permissions model with
this as the front end. They'd have to translate everything to these ints.
In this layer these simply are fields. I think it's reasonable to pack the
booleans into an int, but it should be seperated from the file system. No one
will ever instantiate this class as you two have listed. It's going to be:
FS_Specific_Permissions perm = fs.getPermissions(f);
FileStatus s = new FileStatus(perm.something(), perm.somethingElse())
There's got to be a better design to this. Do you think it would be reasonable
to have two constructors, one taking the booleans packed into an int and one
taking the booleans? I don't want the int to mean anything more than the
booleans.
Lastly, someone should look at the groups code. I don't like it and if someone
came up with something better, I think that'd be great.
> 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.patch4,
> hadoop-user-munncha.patch5, hadoop-user-munncha.patch6,
> hadoop-user-munncha.patch7
>
>
> 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.