Re: Determining if a file is located in the trash from a daemon problem - Getting nsvErr
Re: Determining if a file is located in the trash from a daemon problem - Getting nsvErr
- Subject: Re: Determining if a file is located in the trash from a daemon problem - Getting nsvErr
- From: Jean-Francois Dontigny <email@hidden>
- Date: Mon, 21 Sep 2009 11:12:26 -0400
- Thread-topic: Determining if a file is located in the trash from a daemon problem - Getting nsvErr
Thanks for the reply!
> As far as I can tell FSDetermineIfRefIsEnclosedByFolder can never
> return noErr without also setting *outResult to true. That is, if an
> item is not in the trash, a function result of nsvErr is the expected
> behaviour. Our internal clients always call it like this:
>
> isInTrash = (FSDetermineIfRefIsEnclosedByFolder(... , &result) == noErr)
> && result;
>
Yes, I remember having seen something along these lines in other threads. I
experimented with the function, but my real problem was that the *outResult
was never true.
> btw This non-obvious (and somewhat annoying IMO) behaviour is not
> described in the documentation for the routine. I'd appreciate if
> you could file a bug against the documentation.
>
> <http://developer.apple.com/bugreporter/>
>
Sure thing.
> The above explains one aspect of the problem you're seeing. However...
>
>> Is it possible that I cannot use this function as root? (the code is
>> running inside a daemon)
>
> What do you expect to happen in this case? Keep in mind that each
> user has a separate trash. From the logs you posted, it looks like
> you want it to test whether the item is any user's trash. That's not
> the routine does. It tests whether the item is in a /specific/
> user's trash. If you call it as root, you're testing against root's
> trash (which is "/private/var/root/.Trash" on my system).
>
Ok! That is good to know. It was not clear from the documentation *which*
trash(es) the function would check against. That would explain the behavior
I am seeing.
> What's the high-level goal here?
Alright, the high level goal is to move a file. The move is done by the
daemon directly. The move destination is a CNID and a volume ID. Everything
works very well, and in fact it works a little too well, in the sense that
the CNID of the destination directory remains valid even if a user deletes
the destination directory (for example) via Finder. Obviously, the CNID
remains valid, since the directory has been moved to the .Trash folder of
the user. In such a case, I don't want to move the file to the deleted
directory, but rather to fall back on some other path.
My goal is thus to move a file to a path identified by a CNID and a volume
ID, while making sure that said path has not been put inside any user's
trash. It is probably also worth mentionning that the daemon has no idea
which user could be deleting the destination directory, so it has to check
all the trashes.
> Doing a file system test like this
> from a root process seems like a guaranteed TOC-TOU security bug in
> the making.
Yes, you are right, altough I cannot for the moment think of how this could
be used to exploit the file or the system in my precise usage. I will need
to think about this some more :)
Since this approach seems flawed for the aforementionned reasons, can you
think of another strategy/approach to this problem?
Regards,
JFD
***********************************************************************
This e-mail and its attachments are confidential, legally privileged, may be subject to copyright and sent solely for the attention of the addressee(s).
Any unauthorized use or disclosure is prohibited. Statements and opinions expressed in this e-mail may not represent those of Radialpoint.
Le contenu de ce courriel est confidentiel, privilégié et peut être soumis à des droits d'auteur. Il est envoyé à l'intention exclusive de son ou de ses
destinataires. Il est interdit de l'utiliser ou de le divulguer sans autorisation. Les opinions exprimées dans le présent courriel peuvent diverger de celles de Radialpoint.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden