PDA

View Full Version : Setting permissions in terminal



Exocet
16th February 2009, 01:07 PM
Our company just purchased a bunch of 3 Mobile Broadband modems and we're having issues on some of our shared machines. They're a mix of 10.5.6 and 10.4.11 - we've fixed 10.5 but are still stuck on resolving the 10.4 macs.

The issue appears to be this:
User 1 installs 3's software. It launches, it works fine - great success.
User 2 attempts to launch the software, it bounces in the dock and refuses to open.

This behaviour continues even if you uninstall the software and reinstall it under User 2's account - it will still only launch when logged in as User 1.

Same issue exists on 10.4. We managed to fix the problem after a lot of headbashing - it was something to do with permissions on a lot of the subfiles not being set properly. On 10.5 we easily resolved this by changing permissions for the 3 folder to "read/write" for everyone. Alike so:

http://img.skitch.com/20090216-1uxwbb1ptapeq4a5my4esu4fgm.jpg

My questions are as so:
1) Having everything being set to read/write is this a security risk?
2) The permissions section on 10.4's Inspector looks and seems to behave differently.
2a) Therefore, how can I apply the same permissions above to these files and folders
2b) Because I have to roll this out over several machines I know I can probably use the chmod command in terminal to achieve this - could anybody help me out with the syntax
3) Following on with the chmod is there a way to create a script/batch file to perform this so users can simply run a file to patch the permissions

bennyling
16th February 2009, 01:58 PM
1) Having everything being set to read/write is this a security risk?

I wouldn't say so. If it's only some files which can't be "compromised" in any way (as in, they don't matter to you, and can always be restored to their original state if need be), then I can't really see an issue with leaving them as read/write all.



2) The permissions section on 10.4's Inspector looks and seems to behave differently.

No, not really. It's still displaying the same info as Leopard's Info window - just with different names. You're still seeing the traditional file's owner, file's owner's group, and everyone else view - but because it's a file that wasn't created on your computer (and hence, doesn't have the same perms , you're seeing different names. Example below.
http://www.freshbytes.com.au/images/skitch/leopardperms2-20090216-144852.jpg


2a) Therefore, how can I apply the same permissions above to these files and folders
Try this in Terminal for files:

chmod 0666 /directory/anotherdir/file

and this for folders:

chmod -R 0777 /directory/anotherdir

UPDATED: 0666 didn't seem to be working for folders, so I changed this to 0777. and recursively needs no trailing slash.

Happy to be corrected if I've posted the wrong thing... :confused:



2b) Because I have to roll this out over several machines I know I can probably use the chmod command in terminal to achieve this - could anybody help me out with the syntax

Yep, see above. :thumbup:



3) Following on with the chmod is there a way to create a script/batch file to perform this so users can simply run a file to patch the permissions

Now that's a little trickier. I can't see why you can't just put those commands into a text file and then execute the text file, though. Someone who is actually experienced in bash scripting will be able to do this.

I'll be happy to write the file that you need - assuming that each file name stays in the same place on each computer... I'll need the filenames that you want changed, though :D

sendai
16th February 2009, 07:41 PM
UPDATED: 0666 didn't seem to be working for folders, so I changed this to 0777. and recursively needs no trailing slash.Folders need the execute permission set to be executed (opened.)

Copy the code below into a text-file called "3 MobileBroadband multi-user hack.sh" or something.

#!/bin/bash
#Change the path to the application path. Make sure the quotes are kept.
APP_DIR="/Applications/3 MobileBroadband"
chmod -R 777 "$APP_DIR"
# You can probably ignore the next three lines.
# Un-comment the line below and comment the line above if you get a permissions error
# sudo chmod -R 777 "$APP_DIR"
# P.S. Add a hash "#" before the line to comment it.With the file created, you'll need to "chmod 777 $THE_FILE" the file itself so it is executable. But once that's done, you can double click on it and it'll automagically run in a terminal.

Anyhow, as this is a few hours late, the issue's likely resolved... :)

bennyling
16th February 2009, 07:48 PM
Folders need the execute permission set to be executed (opened.)

Ahhhh - I get it now. Thanks for that, it makes perfect sense when you think about it!




#!/bin/bash
#Change the path to the application path. Make sure the quotes are kept.
APP_DIR="/Applications/3 MobileBroadband"
chmod -R 777 "$APP_DIR"
# You can probably ignore the next three lines.
# Un-comment the line below and comment the line above if you get a permissions error
# sudo chmod -R 777 "$APP_DIR"
# P.S. Add a hash "#" before the line to comment it.


Nice - far more elegant than I would have done it. Good work. :thumbup:

chrome
16th February 2009, 08:46 PM
OSX supports extended ACLs which can short circuit the posix file perms to give finer grained control over things.

The 'chown' manpage gives decent information on this. But I don't think there is anything wrong with doing things the way you suggest.

dotnet
16th February 2009, 11:09 PM
Never make the /Applications directory (or any system directory) world-writable. This is a big security issue.

The 3 app you installed is obviously misbehaving. I suppose the problem is that the app doesn't use per-user plist files and all users try to update the system-wide plist file. Or, some driver got installed with the app that isn't accessible to anyone but admin users (or the use who installed it, giving the admin password during installation). Something like that. Check console.app whether it logs anything while failing to launch.

Widespread single-user thinking among software developers is one of the legacies of the PC era, one of Microsoft's gifts to the world...

Cheers
Steffen.

bennyling
16th February 2009, 11:27 PM
OSX supports extended ACLs which can short circuit the posix file perms to give finer grained control over things.

WOOOOOOOSH*

* sound something makes when it flies over my head.

vecsty
16th February 2009, 11:50 PM
Exocet just as a personal exercise is the software your using publicly available?

Interested to see what its doing.

Exocet
17th February 2009, 09:27 AM
Never make the /Applications directory (or any system directory) world-writable. This is a big security issue.
What about an individual folder contained within?


Exocet just as a personal exercise is the software your using publicly available?

Interested to see what its doing.
I just checked the 3 website but in true form, the "Mac updater" is a windows-only file to update the modem. I'll see if I can publish the mpkg somehow.


The 3 app you installed is obviously misbehaving. I suppose the problem is that the app doesn't use per-user plist files and all users try to update the system-wide plist file. Or, some driver got installed with the app that isn't accessible to anyone but admin users (or the use who installed it, giving the admin password during installation). Something like that. Check console.app whether it logs anything while failing to launch.
I thought this initially - but the issue persists even if the application is completely removed and installed in User 2's account (standard account). To test the theory, I created User 3 and gave them administrative privileges and the same thing occurred. Installed under user 3, the application is still only accessible to user 1. Odd!

I'm out of the office today but will update tomorrow with the file and after some attempts with your solutions. Thank you to all who have thrown in their 2c!

dotnet
17th February 2009, 10:29 AM
Completely uninstalling doesn't always remove plist files and other bits, depending on how diligent the uninstaller is. Tools like AppZapper are quite good at finding all the scattered remains of an app, but I'm sure not 100% accurate all the time.

Also, running as an admin user doesn't mean you have higher privileges. Those accounts are still regular user accounts, the only difference is that they may invoke sudo if they need to carry out an operation as root. This is something the app has to ask for, however, it won't happen automatically.

To prove that this is a file permission problem you could anable the root account, login to the GUI as root and try running the app then. Note, this suggestion is for testing and trouble-shooting only, never run the OS X desktop as root otherwise.

Cheers
Steffen.