Re: FSCopyObjectAsync: useless and crippled
Re: FSCopyObjectAsync: useless and crippled
- Subject: Re: FSCopyObjectAsync: useless and crippled
- From: Hamish Allan <email@hidden>
- Date: Mon, 16 May 2005 11:37:11 +0100
On Mon, 16 May 2005 00:33:21 -0500, "Mark Munz (DevList)"
<email@hidden> wrote:
From a user's stand point, drag-n-drop installation is much
friendlier than forcing the use of an Installer. In fact, the Finder
will require authentication if you don't have privileges, just as I
would expect as a user.
I agree with you about drag and drop installation, but part of the
installer's function is to avoid you having to go through
authorization more than once (which would be the case if you had to
install your BOA in /Library as well as needing write permissions
for /Applications).
However, I also very much agree with you that filesystem access is a
common case, even if your particular case of it is less common. If
high-level APIs are not provided, people will roll their own (e.g.
SubEthaEdit).
It seems to me like you want the following behaviour when the
application is run:
if (BOA not installed in /Library && BOA not installed in ~/Library)
install BOA in ~/Library
and the following in a preference pane:
if (BOA not installed in /Library)
offer to install BOA in /Library if an admin password is given
You have given up on the second because it's not provided at high-
level, but you could well not have decided not to. In which case,
there would be either:
1) A setuid tool responsible whose sole responsibility is to copy a
file from ~/Library to /Library (would require authorization to be
performed twice in order not to be a security risk); or
2) A dialog which asks for the user's admin password, then passes it
to exec(sudo cp).
I think we can probably all agree that the second of those is not
something we want to encourage. I think most people who have tried to
use authorization services would also agree that the first is
difficult enough to ensure correct that it poses a security risk.
So I would ask the people who would argue against a simple high-level
file access authorization service -- do you really prefer the
alternatives?
Best wishes,
Hamish
_______________________________________________
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