Re: FSCopyObjectAsync: useless and crippled
Re: FSCopyObjectAsync: useless and crippled
- Subject: Re: FSCopyObjectAsync: useless and crippled
- From: James Bucanek <email@hidden>
- Date: Sat, 14 May 2005 09:23:22 -0700
Steve Gehrman wrote on Friday, May 13, 2005:
>
>>> For example, If I'm trying to copy a file that I don't have read
>>> permission for, The API needs to ask the user for the Admin password,
>>> or at least give my app the opportunity to handle this case.
>>
>> You want FSCopyObject to pop-up a dialog and ask the user to
>> authenticate a copy of a file they don't have permission to read?
>> Then switch to privileged execution mode if it needs to?
>> Automatically?
>
>Yes. Why not? Isn't OS X a modern operating system? Why should it
>be so difficult?
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.
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.
>> That's insane. You can't have low-level file APIs popping up
>> interactive user windows or escalating privileges for a process.
>> If you don't have permission to access a file, and you have to go
>> through the authentication framework to gain authorization to do
>> so, then that is *your* responsibility to take those steps -- not
>> FSCopyObject's.
>>
>
>What the difference? Either I write an API from scratch, or Apple
>provides an API. Either way the outcome is the same.
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.
>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.
>What's insane is that the Apple APIs are so pathetic. I can't believe someone
>actually got paid to design and write such crap.
I was going to write something snippy here. But this statement is so juvenile, that I'll let it make its own impression on the reader.
>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.
>Yeah, easy to do, I've written all the code that does this already.
>But these are brand new APIs, just released in Tiger. I had hoped
>that they would work as promised.
They certinaly work as promised. They just don't work as you expected.
>The problem with these APIs is that there is no way to intercept errors. It's
>all or nothing.
Since it's sort of an "all or nothing" API (copy files or don't), I don't see how this is unexpected or even unavoidable. Would you like the API to return an array of OSErr codes, one for each operation it had trouble with?
If you want to intercept each step of the copy process yourself, write your own or adapt any of the comprehensive file copy examples which have been written already.
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.
--
James Bucanek <mailto: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