l4-hurd
[Top][All Lists]
Advanced

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

Directories traversal (was Re: the deadly hypercube of death, or: handli


From: Pierre THIERRY
Subject: Directories traversal (was Re: the deadly hypercube of death, or: handling permissions)
Date: Fri, 28 Apr 2006 00:20:57 +0200
User-agent: Mutt/1.5.11+cvs20060403

Scribit Marcus Brinkmann dies 27/04/2006 hora 18:37:
> A directory has lookup, which would require read capabilities, and
> link, which would require write capabilities.  I think it is useful to
> give some programs only lookup/read access to a directory and not
> link/write access.

After thinking on it for quite some time, there is something that I feel
I don't understand fully: how would directories traversal work in a
capability-based directory hierarchy (FS or not)? In fact, I think we
need some additional permissions at the directory level:

If I have a lookup cap on a dir, I suspect i'll be able to know it's
entries list and acquire a lookup cap on them. So if I have a lookup cap
on the root of a filesystem, I seem to be able to read it's entirety. I
think eiter I'm missing something, or there's a problem.

I think we should have much more dir_t capabilities, that would express
not only the permissions on the dir itself, but also what kind of
permission we could gain for it's entries, if any.

In the current ACL scheme, you specifiy the permissions for every entry,
so some user could enter your $HOME dir (--x), enter a dir he already
knows the name, and read it's content (r-x), and then read some files
(r--), some others not (---).

We have basically two choices: either the user has to give a cap or a
set of cap for each dir and dir entry he want's to allow access to
someone else (like he has now to do with ACLs), or we have to have some
capabilities that let the dir know what type a capability it can give on
it's entries. And we can have both in the same system, coexisting. Maybe
we will have anyway.

Doubtfully,
Nowhere man
-- 
address@hidden
OpenPGP 0xD9D50D8A

Attachment: signature.asc
Description: Digital signature


reply via email to

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