RE: Xcode default "Install Permissions", clean "permission denied"
RE: Xcode default "Install Permissions", clean "permission denied"
- Subject: RE: Xcode default "Install Permissions", clean "permission denied"
- From: "Alex Sheh" <email@hidden>
- Date: Mon, 27 Aug 2007 10:33:40 -0700
- Thread-topic: Xcode default "Install Permissions", clean "permission denied"
Thanks for pointing that out (/Applications folder, bundle permissions).
I also looked at the legacy "Software Distribution Guide", and it
suggests the following permissions,
http://developer.apple.com/documentation/DeveloperTools/Conceptual/Softw
areDistribution4/Concepts/sd_permissions_author.html
"Set permissions for the directories and executable files in the package
to a value of 775 (full access for owner and group, read and execute
access for others).
Set permissions for non-executable files to 664 (read and write access
for owner and group and read-only access for others)."
Since it is recommended by Apple, I'm going to go with 775 "Install
Permissions" for my release bundle. I wanted to go with 555 because
this would prevent users from writing to my executable, but it looks
like 775 is the way to go.
Does anyone know why we need 775 permissions for executables? I thought
that the reason is because both root and admin need write priveleges
inorder to delete the executable. However, I tried deleting an
executable that had permissions 555 root:admin, and was able to delete
it via the Finder.
Thanks,
Alex
-----Original Message-----
From: Kyle Sluder [mailto:email@hidden]
Sent: Wednesday, August 22, 2007 8:05 PM
To: Jack Repenning
Cc: Alex Sheh; James Bucanek; email@hidden
Subject: Re: Xcode default "Install Permissions", clean "permission
denied"
Actually, it's a one-liner in AppleScript. ``tell application "Finder"
to move the file "Macintosh HD:Users:...:Bundle.app" to the trash``
You still haven't explained why your users should not be able to write
to the bundle. Pick any file in /Applications and you'll see it's 775
root:admin. Do you really have a compelling reason for your app to be
different?
In fact, perhaps you should consider filing a bug to change the default
deployment permissions to something more reasonable, like "o-w,a+rX".
--Kyle Sluder
On 8/22/07, Jack Repenning <email@hidden> wrote:
> On Aug 22, 2007, at 6:54 PM, Alex Sheh wrote:
>
> > The main issue is that when I try to clean the configuration, Xcode
> > needs to be able to "rm" the previously built Bundle.app. However,
> > Xcode can't do this because the folders aren't writable, and the
> > clean fails. So basically developers can't clean from within Xcode
> > and have to manually remove the folder themselves, which doesn't
> > make for an efficient workflow.
>
> Yes ... it is possible to Trash these folders without extra
> authentication, so I thought of adding an AppleScript step to the
> clean target to have Finder trash 'em. Only you can't add scripts to
> the clean target, and anyway Finder doesn't have an Apple Event for
> "trash this."
>
>
>
> -==-
> Jack Repenning
> email@hidden
> Project Owner
> SCPlugin
> http://scplugin.tigris.org
> "Subversion for the rest of OS X"
>
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden