l4-hurd
[Top][All Lists]
Advanced

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

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


From: Bas Wijnen
Subject: Re: Directories traversal (was Re: the deadly hypercube of death, or: handling permissions)
Date: Fri, 28 Apr 2006 14:01:33 +0200
User-agent: Mutt/1.5.11+cvs20060403

On Fri, Apr 28, 2006 at 01:44:35PM +0200, Pierre THIERRY wrote:
> Scribit Marcus Brinkmann dies 28/04/2006 hora 01:54:
> > > Where will these user mutable filesystem reside?
> > Whereever we want it to be.  It could be in the form of a union
> > filesystem.
> 
> Have you already thought about how exactly this could be implemented? In
> Unix, users typically occupy a partition, where they can have quotas or
> not. The FS deals with allocating space to each user. If each user has
> it's FS, we must at least add an allocator layer between the storage
> itself and the user. This could be LVM or some sort of it.

The user has a space bank on which he can store data.  Sub-space banks can be
created from it and given to programs it starts.  Space banks can be limited
to a certain size.  If you limit a user's space bank, that comes down to a
quota.

> Speaking about the users' dir, I was also wondering about how backups
> could be made of a FS that contains arbitrary translators.
> 
> In the case of $HOME, it would probably be a waste if you backup the
> entire space allocated to the user, in same sense that is a waste to
> backup the content of a block device instead of the files contained in
> it. I think either the user gives a transitive read-only capacity to
> it's $HOME, or a capacity whose invocation returns a compact view of the
> underlying data of it's FS. It could even be encrypted, if the backup
> user should not be able to read $HOME.

I think it's a very bad idea to give the system administrator read access to
all your files, just because he wants to make backups.  There already is a
form which can be used for recovering, because we have a persistent system.
Making a backup should simply consist of copying the snapshot.  The question
is who should have the right to do this, but it makes sense that there is at
least a capability for it.

To get rid of the block device/files problem, only allocated parts of space
banks should be backed up, and not the entire allocatable space.  Optimising
more than that will lead to security and privacy issues, I think, and it's not
important enough that we should risk that.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

Attachment: signature.asc
Description: Digital signature


reply via email to

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