Authorisation catch-22 with NSOpenPanel
Authorisation catch-22 with NSOpenPanel
- Subject: Authorisation catch-22 with NSOpenPanel
- From: Tim Hewett <email@hidden>
- Date: Thu, 25 Nov 2004 14:30:31 +0000
Hi,
I've encountered a catch-22 with the authorisation architecture.
By "authorisation architecture" I mean the way that authorised
operations should be compartmentalised in a sub-executable
which runs SUID to root, rather than creating bad security holes
by having the main app run as root.
My app needs to access restricted files when authorisation is
given, which is fine - it all works great in the sub-executable running
as root while the top executable runs as the normal user. The
problem is that the user sometimes needs to browse down into
restricted folders in NSOpenPanel, but those panels only run in
the context of the main GUI process hence there is insufficient
privilege to do this.
It would be helpful if NSOpenPanel could provide an alternative
way to acquire the file list it uses to display, then I could add a
new authorised facility to the sub-executable to produce a file
list for a given path with root privileges. There doesn't appear to
be such a facility so I tried an alternative approach by using the
objective C class_poseAs() function to provide a way to intercept
the NSFileManager directoryContentsAtPath: selector (by subclassing
NSFileManager and then having my subclass pose as NSFileManager).
Hee hee hee... nope. NSOpenPanel does not use NSFileManager
to get its directory file list, I have no idea what it does use but it
isn't
NSFileManager.
I need to find some way of intercepting the mechanism NSOpenPanel
uses to get the file list for its displayed folder... is this possible?
Maybe there's an alternative solution to the underlying problem of
access to privileged folders in NSOpenPanel? I don't want to have
the authorised sub-executable display the NSOpenPanel itself as
this would mean linking to the Cocoa framework and the appearance
of a new security hole...
Any ideas gratefully appreciated.
Cheers,
Tim.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden