Re: Getting file icon in authorised executable
Re: Getting file icon in authorised executable
- Subject: Re: Getting file icon in authorised executable
- From: Finlay Dobbie <email@hidden>
- Date: Mon, 6 Dec 2004 13:12:02 +0000
I believe NSWorkspace uses the Carbon Icon Services - which might be
in CoreServices if you're lucky.
-- Finlay
On Sun, 5 Dec 2004 16:04:58 +0000, Tim Hewett <email@hidden> wrote:
> Hello,
>
> I am trying to implement a replacement for NSOpenPanel which can
> display files stored in privileged folders, i.e. ones which you need to
> provide admin authentication to see. It is based on the SimpleBrowser
> example but with the file list being gained via an authorised sub-
> executable running SUID to root (as per the authorisation architecture).
>
> The problem is that I still want it to display the icon for each file
> just as
> SimpleBrowser, NSOpenPanel, Finder etc. do, but that information will
> need to come from the authorised sub-executable too since only
> that is able to read the privileged files.
>
> The problem is this: the whole idea of placing privileged operations in
> the sub-executable is so that security holes are removed by having it
> link only with the most fundamental libraries. To use
> [[NSWorkspace sharedWorkspace] iconForFile:path] would mean
> linking with the Cocoa libraries, something which I believe would open
> a security hole large enough to drive a bus through. There seem to be
> a number of "toll-free bridges" between Cocoa and core foundation
> objects (e.g. NSData and CFData), is there an equivalent for
> NSWorkspace? Or is there some other way to get an icon for a file
> which produces the same results as the NSWorkspace iconForFile:
> method but which doesn't need linking to libraries which would
> create a security hole? What does NSWorkspace's iconForFile:
> call itself to return the icon image?
>
> Once the icon has been read it can be transferred up a pipe to the
> main GUI process... it is just a matter of finding a way to read the
> icon
> in the authorised executable while retaining security integrity.
>
> Any hints much appreciated.
>
> 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
>
_______________________________________________
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