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 00:37:12 +1300

Thanks for the info.

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??).

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?

Thanks
Shams

-- 

<olafBuddenhagen@gmx.net> wrote in message 
news:20070205175236.GB319@alien.local...
> Hi,
>
> On Mon, Feb 05, 2007 at 05:20:10PM +1300, Shams wrote:
>
>> 1. Does/will Hurd support something like built in version control of
>> files/directories (just like CVS) eg. achieval if one can install some
>> sort of fs filter driver, can this be done via translators?
>
> Yes, this can be implemented with translators. AFAIK it hasn't been done
> so far.
>
>> 2. What about ACL at file or directory level? Now I believe auth
>> server will play some role in this? Or will a translator play a role
>> in this.
>
> I guess you mean POSIX ACLs? These would have to be implemented in the
> individual filesystems (ext2fs translator etc.), just like on any other
> system. I don't think auth plays any role in this. (Not sure though...)
>
> Note that it's questionable whether POSIX ACLs are useful at all... If
> you need access permissions that can not be expressed using the ordinary
> access bits (which are more powerful on the Hurd than on UNIX, because a
> single process can have several UIDs), you are probably better off using
> capabilities (Mach port rights in the current implementation) directly.
>
> Unless of course you want to use some program that relies on POSIX ACLs,
> and thus need compatibility...
>
>> 3. Now translators can they be developed so that they can be layered
>> on top of each other?
>>
>> - an even higher level translator to print out the contents of xfiles
>> via http. - a translator sits here to control who can access this
>> directory for finer control /mnt/xfiles
>
> Not sure what you mean exactly, but yes, translators can be layered. In
> fact, every disk FS translator normally is layered on top of a store
> translator.
>
>> 4. Is it possible for translators to talk to each other or more
>> specifically is a translator just another server?
>
> A translator is just a server attached to a filesystem node, and
> usually, but not always, implementing an FS interface itself.
>
> A translator can talk to other translators, just like any other programm
> can.
>
> BTW, this kind of questions would be more appropriate on
> bug-hurd@gnu.org .
>
> -antrik- 







reply via email to

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