help-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Hurd features (continued)


From: Shams
Subject: Re: Hurd features (continued)
Date: Sun, 11 Feb 2007 12:11:57 +1300

Thanks for the info,

Regarding metadata:
I mean in the filesystem. Currently ext2 is used as the default filesystem
for Hurd. Now if you have a look at Reiser4 (or similar) then it has
the possibility of assigning attributes (key - value pairs) to a file or
directory. It also has built-in journaling capabilities.

ext2 I believe is very limiting in these cases. Linux for example has moved
from ext2 as being the default fs a long time ago and now uses ext3 as the
default filesystem. Also Reiser3 has been merged into the mainstream kernel
too and I think Reiser4 will be a likely candidate in the near future to be 
merged
into mainstream too.

So what progress have or are we making to use something like ext3, Reiser3, 
Reiser4
or XFS or similar in Hurd as the default filesystem?

Thanks
Shams

-- 

<address@hidden> wrote in message 
news:address@hidden
> Hi,
>
> On Sun, Feb 11, 2007 at 12:37:12AM +1300, Shams wrote:
>
>> Does/will Hurd support metadata capabilities or once again can/do
>> translators play a role in this? If translators were the case then how
>> could it achieve this (via extended attributes??).
>
> No idea what you mean.
>
>> Could you please eloborate on ACL vs UID part a bit more.
>>
>> Here is the scenario 1. UserA creates a file and wants to grant access
>> to lets say 5 groups via ACL (each group containing a certain number
>> of users) to a certain file.
>>
>> Then how does UID solve this problem?
>
> UIDs don't solve this problem.
>
> The standard UNIX solution is very simple: Create a group with all users
> allowed to access the file.
>
> The presented scenario is extremely unlikely in practice, and in fact it
> demonstrates a common misunderstanding of the UNIX group mechanism:
> Groups do not represent any kind of "teams" or whatever; rather, groups
> are tied to specific uses. If you want more abstract "teams", you need
> an admin tool that manages them in an own database, and maps them to
> UNIX groups as needed.
>
> Of course, in UNIX, only the admin can create groups, which can be a
> serious limitation in some situations. (Which is only very poorly solved
> by POSIX ACLs IMHO.) The hurdish solution is to run an your own access
> control mechanism, and do whatever you want. You could run your own
> filesystem that uses different rules to decide who is allowed to access
> the files. Or, probably more useful in most cases, you still store your
> files on the system-provided FS, but you run a proxy FS server that
> implements your own access scheme on top of it. This can be POSIX ACLs
> if you really want them, but it can also be anything else you can think
> of.
>
> -antrik- 







reply via email to

[Prev in Thread] Current Thread [Next in Thread]