Thank you for your answer, You're right : it's impossible that a system leaves the choice to its applications of respecting or not permissions. The problem is that QS indexed the folder before I changed permissions, exactly as you said.
I still don't understand why QS can stay connected to that folder and execute files even if I applied these modifications a long time ago (I shut down the computer everyday). Don't you think this is a security problem with Mac ? Because you never can be certain that a folder has been read or not by another user before you change its permissions... Thanks. On Sep 11, 2:37 pm, Rob McBroom <[email protected]> wrote: > On Sep 11, 2009, at 2:07 PM, Kaïs wrote: > > > I have a folder with the following permissions. > > - me : write only (drop box) > > - staff : write only (drop box) > > - others : access forbidden > > > This folder is not shared, and is locked. For example, I can't access > > this folder or contained files using Finder > > > However, files inside this folder can be seen in a simple search of > > Quicksilver... Moreover, I can read or open these files through > > Quicksilver even if I don't have permission. > > > Is there a problem with access permissions in Quicksilver ? > > Applications can't just ignore permissions (due to a bug or any other > reason). That wouldn't be a very good security system at all. > > Quicksilver runs as a user. If that user can access something, so can > QS and vice-versa. Also, Quicksilver doesn't directly open most files. > It tells another application to open them (or tells the Finder, > perhaps, which then tells the application), so if you're able to open > the files, it's more than just QS that has access. > > I have to think you have access to these files somehow. Is it possible > Quicksilver indexed the files before you changed the access? If so, > you should be able to bring up QS and hit ⌘R to have it re-index > everything. > > Perhaps you could open a Terminal window and run `ls -le /path/to/ > folder` and send us the output? > > -- > Rob McBroom > <http://www.skurfer.com/>
