Re: FSCopyObjectAsync: useless and crippled
Re: FSCopyObjectAsync: useless and crippled
- Subject: Re: FSCopyObjectAsync: useless and crippled
- From: "Mark Munz (DevList)" <email@hidden>
- Date: Sat, 14 May 2005 18:47:02 -0500
On May 14, 2005, at 11:23 AM, James Bucanek wrote:
Steve Gehrman wrote on Friday, May 13, 2005:
Because it's a difficult problem. What you're complaining about is
not that FSCopyObject doesn't do it's job. You're complaining that
it doesn't handle the extraordinary case of accessing a file that
the USER DOES NOT HAVE PERMISSION TO ACCESS. That's the point of
access privileges -- they are supposed to prevent your process,
using any system function, from accessing those files.
First -- Apple has always made it difficult to copy files, period. As
I recall, even in OS 8/9, you had to use their provided sample code
to correctly copy a file (w/o any permissions issues). They never
supplied an API that would copy both forks of a file, that always had
to be done manually (or with sample code).
Copying files CAN be a difficult problem, but it is one that is both:
1. Very Common
I'm betting that virtually every developer has to deal with this on
their own and that most of the authentication is for something like
copying files to the machine library. In fact, if Apple provided the
functionality, they could better alert the user to the level of
security that is being called upon.
2. Already Developed by Apple
It seems that the Finder essentially does this already.
What you are proposing is to break down the security of the system
for your convenience. This is, admittedly, a persistent problem in
the entire system. "Secure" and "user-friendly" are two properties
that are often mutually exclusive. But I don't see that it's
appropriate to ask an FS... level API to start second guessing the
need to authenticate to make a copy of a file the user shouldn't,
by rights, have any access too.
I would like to see Apple provide an 90% solution for copying files.
Don't make it a low level call, make it more of upper level call,
sort of like NSWorkspace.
No, there's a third solution which is very common. Someone, often
Apple, can write a library or sample application code which does
all of the dirty work for you. You can incorporate, modify, and
customize this code as needed. Because, often, it requires
customizing simply because these are not simple problems with one-
size-fits-all solutions.
I never liked this approach mainly because I think Apple should be
solving this problem for 90% of the people with an appropriate API,
and THEN providing customized solutions for the other 10%. Instead,
every app has to include this code (most of the time it is probably
included unchanged).
The problem is that for a modern OS, copying a file should be easy.
Copying files *is* easy. Copying files you don't have permission
to copy should be hard -- if not impossible.
Yeah -- drawing fancy graphic is also difficult, but Apple does it. I
think the problem is that Apple isn't dealing (nor ever has dealt
with) the most common case via an API.
The API could and should launch it's own setuid tool and handle all
the communication and pass info to the app. If the app doesn't want
user interaction, then the app can turn it off. Just like the alias
resolving APIs. There are options for "no user interaction"
This argument can be extended, ad absurdum, to the entire FS... API
suite. Why shouldn't FSOpenFork automatically authenticate the
user, fire up a helper app, hand back a Distributed Objects proxy,
and allow you to access a file you don't have permission to read?
Why should I, the lazy programmer that I am, have to deal with
"insufficient privileges" errors? What's that all about?
You're not demonstrating that the FSCopyObject has any deficiency
or flaw. You're only demonstrating that FSCopyObject has the same
process and security limitations that every other file system
function has. Namely, that they properly enforce the security and
permissions model of the OS. As far as I'm concerned, if you want
to side-step those restrictions, that's your responsibility -- not
the low-level APIs.
Yes, this could be extended to absurdity -- but I think it is fair to
think that an OPERATING SYSTEM could provide a most commonly used
method of copying/moving files.
It seems like you see this as a low-level API issue, where I agree it
shouldn't be handled. But I do think Apple should provide a high-
level, user authenticate-able (ugh!) file copy API. I think it would
actually be more secure from the fact that it doesn't require the
developer to insure all the right permissions were granted to the
right things (ie. where you accidentally gain authentication for
anything the app does).
Besides, if you want to copy something with root access using a
helper application, that's already there. Authenticate the user,
then use LuanchExecutableIWithPrivileges (or whatever it's called)
to run the 'cp' command as root. Sloppy, and probably not
recommended from a security standpoint, but it would work.
I think this last statement makes my previous argument.
I would recommend filing an enhancement request for a high-level file
copying API. Maybe if enough developers request it, Apple will
actually do it. It may not handle 100% of the cases, but I'm betting
the reality is that if they can NSWorkspace filecopy the ability to
put stuff in restricted folders (like /Library/ for example), it
would probably cover 80-90% of the need for the Security APIs. Just a
guess, but that is all I've ever needed them for.
Mark Munz
_______________________________________________
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