lkml.org 
[lkml]   [2000]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: (reiserfs) Re: NFSv4 ACLs (was: ...ACL's and reiser...)


"Ragnar Kjørstad" wrote:

> On Sun, Aug 06, 2000 at 06:44:45PM +0200, Xuan Baldauf wrote:
> > P.P.S.: To the question: "What are you storing in the cache?": I store the list of
> > pending acl-change orders in the cache. (The word cache was quite misleading.
> > Sorry.)
>
> What if the data changes before your background thread have finished
> updating the ACLs?
>
> 1. change ACLs for /dir recursively
> 2. chage ACL for /dir/file
> 3. thread executing (1) changes ACL of /dir/file

I knew that this question would come. So order the list of requested changes (the most
recent one at top, the oldest one at bottom). The background thread popps the orders
from the bottom, always hurrying to be in current state. The check (if the list is not
empty) has to work like going from top to bottom. (I say "has to work like", because you
can think if implementations where checking is implemented with a tree. If a match in
this tree is found, there should be tests wether the the inner entry (/dir/file) or the
outer entry (/dir) is newer.

For people imagining a DOS attack on filling the list: restrict the list size and make
all further attempt to add an entry block.

> Is the time spent in the change-acl systemcall an issue at all? If the
> user wants this to be a background task, ha can just fork, right?

People (especially Windows users) tend to wait for one action to complete until starting
the next one. Imagine someone who wants to give rights to user "httpd" and then tries to
access his own web pages. Or imagine (at an ISP) a (virus|mp3|*) scanning tool which
should get access to 10000 customer homepages. Conventional acl changes would need hours
forcing the sysadmin to idle until he|she can start test-scanning on a wide range.

Yes, you can write scripts which sequentialize tasks, and yes, you can even attach a
script sequentially ( while test -e /proc/pid; do sleep 5; done;
do_something_after_the_process_died ). But those approaches are limited to command line
interfaces, sadly modern GUIs do not have capabilities to queue tasks into the future.

>
> (Yes, I know it will not be atomic - is that an issue?)

It should not be. Making the operation atomic is just a possible side effect. (Though
people might find applications for it.)

>
>
> --
> Ragnar Kjorstad
> Torque Systems / Big Storage

Xuân. :o)




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:58    [W:0.583 / U:0.888 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site