hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christophe Taton (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HADOOP-1298) adding user info to file
Date Wed, 25 Jul 2007 07:04:33 GMT

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

Christophe Taton updated HADOOP-1298:
-------------------------------------

    Attachment: hadoop-dev-20070724-2349.patch.gz

Hi all,

Ok, I am currently extracting the smallest patch I can, removing anything not needed for ownership
and access rights.
Attached to this mail is the current state of the patch, which is still not acceptable.

The patch is still insane if you read it directly, mostly because svn diff did a very bad
job for FSDirectory (lost as soon as it reaches an insertion or a removal of a method).

FSDirectory is the bigest change: the file grows from ~800 lines to ~1600 lines mostly because
of javadoc. I removed most of the javadoc updates so as to minimize noise.

There are changes related to some kind of uniformity between the way methods are written:
an operation that may update the edit log is divided into three parts: one private method
with a boolean parameter that indicates whether the operation should be logged or not; one
method that systematically update the log; and one that never update the log. I made this
change as it was a real pain to trace the many call paths when I started testing and debugging...

I changed the FSImage to integrate a simple user database and file ownership and mode info.
In doing this, I made INode implement Writable. This could possibly be the purpose of another
patch.

In the end, most of the other changes were done so as to limit access rights checks mainly
to the following INode operations: getINode(), addFile(), delete().

Some notes:
- FSDirectory.INode contains 2 equivalent methods: computeName() and getAbsoluteName().
- Many constructors are unused and removed. Should I put them back?
- obtainLock and releaseLock are unused. Should they be updated? marked as deprecated? removed?
- What is the policy against imports? Should I keep imports containing wildcards?

Christophe T.


> 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
>             Fix For: 0.15.0
>
>         Attachments: hadoop-dev-20070720-1633.patch.gz, hadoop-dev-20070724-0020.patch.gz,
hadoop-dev-20070724-2349.patch.gz, 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.patch17,
hadoop-user-munncha.patch4, hadoop-user-munncha.patch5, hadoop-user-munncha.patch6, hadoop-user-munncha.patch7,
hadoop-user-munncha.patch8, hadoop-user-munncha.patch9, hdfs-access-control.patch.gz
>
>
> 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