Re: FSCopyObjectAsync: useless and crippled
Re: FSCopyObjectAsync: useless and crippled
- Subject: Re: FSCopyObjectAsync: useless and crippled
- From: email@hidden
- Date: Sat, 14 May 2005 14:50:21 +1000
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?
What I suspect the original poster was trying to say, aside from the
practical issues, is that this is a security nightmare - I don't want
any app which happens to copy files occasionally getting root
privileges. Even if it asks me for them; users are too compliant
with typing their password, since they're prompted for it a dozen
times a day.
Permission issues like this are thornier than most people
acknowledge... while I really appreciate the new ability in Panther's
Finder to authenticate when required for a copy/move/whatever, that's
only because I trust the Finder. For 3rd party apps, I'd much rather
fix the permissions myself, manually, than give them dangerous
privileges.
What the difference? Either I write an API from scratch, or Apple
provides an API. Either way the outcome is the same. The problem
is that for a modern OS, copying a file should be easy. 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.
It would be *nice* if copying a file were easy; in reality, exactly
*because* MacOS X is a modern OS, there are many potential issues
with copying any arbitrary file. For simplicity, we could all just
go back to MacOS 9. Hope you're not used to having private data.
Btw, please keep your tone civil on the list, particularly when
talking about Apple engineers. We all get frustrated at times, but
don't go saying things you'll regret. Apple's engineers do a pretty
fantastic job most of the time, all things considered. They've been
making a noticeable effort to become more accessible and approachable
since the release of Tiger, which comments like yours are only going
to discourage.
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"
Since it's a bad idea to have a GUI app setuid, that requires either
an extra GUI app just for the interface, or the 3rd party app in
question to display the dialog. The latter isn't really an option
from a security point of view. The former is a fair bit of
complexity - this whole process could take tens of seconds, which
means you [ideally] have to design your app asynchronously around
it. You also need to be able to provide precise instructions about
what you're doing to the GUI, so it can display them to the user
properly and so the setuid tool can perform them... that then causes
further issues if things don't go according to plan - like you run
out of disk space, or there is another [different] permissions error,
etc etc. Lots of callbacks? Nightmare.
Irregardless, this is a Carbon question and you should probably
ask on the Carbon list.
Yeah, and get more non-answers.
Please, such comments are unnecessary.
I agree that the current implementation is lacking - I'm really just
playing the devil's advocate here. But there's better ways to go
about solving it, than just getting cranky on mailing lists. If you
have a superior system, please do submit it to Apple, in whatever
form you have*. Until then, yes, your complaint has been noted, so
now you'll have to give Apple some time to digest it (if you're not
going to solve it yourself).
* = Note that sending code to Apple sometimes makes them cranky...
some legal B.S. Either include a legally valid license (e.g. BSD,
APSL) or legally valid provision of rights to your unsolicited
submission.
Wade Tregaskis (AIM/iChat, Yahoo & Skype: wadetregaskis, ICQ:
40056898, MSN, audio/video iChat & email: email@hidden,
Jabber: email@hidden)
-- Sed quis custodiet ipsos custodes?
_______________________________________________
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