#26 GIMP only usable by first user that runs it

[Chevy]

GIMP 2.6.8p1 OSX PPC 10.5.8
GIMP strangely copies some or all of the .app directory to a new directory called /tmp/skl. This directory is owned by the user running GIMP, and it is NOT deleted after the user quits GIMP. As a result, no other user on the system can run GIMP, because other users can't access the skl directory created by the first user that runs GIMP. The problem may be because the developers never operate on a multi-user Mac, or because their multi-user setup uses promiscuous permission settings that allow other users to access the directory /tmp/skl.

Suggestions: delete /tmp/skl when quitting GIMP,
OR delete /tmp/skl when starting GIMP,
OR create /tmp/skl and all its contents with the proper permission settings (suggest POSIX permission settings, since they are much simpler and more portable than Apple's ACLs)

[Simone Karin Lehmann]

hhmm,, that sounds weird. This issue was solved in one of the first releases I've made about one year ago.

The directory /tmp/skl is just a symbolic link to the GIMP application bundle. On a standard Mac OS X system, the permissions should be set to world-readable and writable. So the the issue you describe shouldn't happen.

Just take a look at the file

/Applications/Gimp.app/Contents/Resources/srcipt

This script will create the sysmbolic link /tmp/skl to the real location of th app bundle and set the permissions to world-writable. Since Mac OS X uses umask 0022 as default, this results in a world-readable and writeable lin /tmp/skl.

http://support.apple.com/kb/HT2202

world-writable is necessary because /Applications/Gimp.app/Contents/Resources/bin/gimp launches a per-user dbus daemon, which is needed for drag&drop support (on GIMP's icon)

I've just tested this on my system (SnowLeopard 10.6.3, GIMP 2.6.8p2). i've launched GIMP as uuser one, switched to another user, and could start GIMP there too, without any problem (hhm, the only thing is, that both users have admin priviliges, so I should test this with user perms only...)

I've checked the Leopard packages too. And /A/G/C/R/script is identical to the SL version, so permissions for /tmp/skl should be world-readable and writable 8unless you have _not_ set a custom umask)

[Chevy]

I was worried when I first read your comment, because /tmp/skl on my system is a real directory, not a symbolic link. But you must have been sleepy when your wrote, because the script confirms that /tmp/skl is a real directory. The symbolic links are the app and help below /tmp/skl.

Our organization does not accept Apple's promiscuous 0022 umask, which relies on the added (and confusing) layer of ACLs to protect newly created items. We use a global /etc/launchd-user.conf of 0077.

But that gave me enough of a clue to try some things. The directory /tmp/skl had permissions 722 (drwx-w--w-). I changed it to 1733 (drwx-wx-wt), which adds execute for group and other (to allow traversal into the directory) and the sticky bit (just to be sure users couldn't change anything they didn't create). Without the sticky bit, a userid with knowledge of the structure might cause trouble with directory write privileges.

I also changed the symbolic links from 700 (lrwx------) to 755 (lrwx-r-xr-x). This has to be done with chmod -h, so chmod doesn't operate on the target of the symbolic link.

So I suggest that 'script' have a couple simple changes:
Line 17:
FROM: chmod a+w /tmp/skl
TO: chmod 1733 /tmp/skl
A new line 19 after line 18:
chmod -h 755 "$LNDIR"

And a new line after the current line 29:
chmod -h /tmp/skl/Gimphelp

I did one other thing after the installation, to be sure all the files copied from your original distribution still had adequate permission settings for all users.
cd "$APPDIR"
find ./ \( -perm -400 -and ! -perm -4 \) -exec chmod -h a+r {} \;
find ./ \( -perm -100 -and ! -perm -1 \) -exec chmod -h a+x {} \;

These lines could be inserted in 'script' after the new line 19. Although they take a little more time, they are (theoretically) only run the first time GIMP is run.

Thanks for the quick response. I hope this is helpful.

[Chevy]

Sorry for the typo below.
"And a new line after the current line 29:
chmod -h /tmp/skl/Gimphelp"

Should say:
"And a new line after the current line 29:
chmod -h 755 /tmp/skl/Gimphelp"

[Simone Karin Lehmann]

hhmm, some of your changes look very interesting, and yes your right, /tmp/skl is a directory (sorry.)

But what about the dbus daemon pid file? It's generated by /Applications/Gimp.app/Contents/Resources/bin/gimp and is needed for drag&drop support by /Applications/Gimp.app/Contents/Resources/bin/gimp-remote.

What if one installs GIMP as an admin? Are the find / chmod commands still working?

[Chevy]

I've done more testing, and concluded the solution is only one of the steps I've written about.

Line 17:
FROM: chmod a+w /tmp/skl
TO: chmod 1733 /tmp/skl

(On the symlinks: It's been many years since I dealt with symlink permissions, and I forgot that they don't need permissions for group/other if you don't expect people to use them directly (ls -al and cd won't work, but your app will still work).)

The dbus file will work as expected with permissions set to 1733 on /tmp/skl, and you'll have the added benefit of the sticky bit and a write-only /tmp/skl.

I installed as both an admin and a regular user (which requires OSX's sudo authorization to copy to /Applications). With the 1733 tweak to /tmp/skl, both techniques worked.

I also installed GIMP in a shared app directory that we use for non-Apple applications, that worked, too.

--

I have an unrelated comment about help, which I can put in a separate report, if you'd like. The current package appears to install help in ~/Application Support/Gimp for each user (taking more disk space with each user). After I installed help the way the package installs it (local), I created /Library/Application Support/Gimp/, and moved ~/Library/Application Support/Gimp/help to /Library/Application Support/Gimp/. I then changed /tmp/skl/Gimphelp to point to this new help directory: Moving it to /Library requires admin privileges, but that's not an unreasonable requirement for an installation.

rm -f /tmp/skl/Gimphelp
ln -s "/Library/Application Support/Gimp/help" /tmp/skl/Gimphelp

If you decide you like things this way, perhaps you might put these two commends in 'script' while you're making changes for the next release.

Many, many thanks for the work you've done to get this out!

[Chevy]

Sigh. I have to correct one thing, although it is not that germain to the issue. I said "(ls -al and cd won't work, but your app will still work)". Actually cd will work, but trying to list the target of the link won't work (i.e. ls -al /tmp/skl/Gimphelp).

[~suv]

With regard to the Help files:

monzav8 wrote:
> Moving it to /Library requires admin privileges,
> but that's not an unreasonable requirement
> for an installation.

For me this would only be acceptable as optional Installer download, but never as basic requirement to "install" GIMP or its help files on OS X - please keep it as easy as is (DnD GIMP.app wherever the user wants it to go, and _not_ providing an installer package for GIMP as well - I can handle extracting the help files from the installer, but I'd rather not have to for GIMP.app as well) and avoid requiring 'admin' privileges (or installer scripts using 'sudo').

BTW - the most limiting factor IIRC [1] in how the help files are checked for is that symbolic links to the help file directory (i.e. in ~/Library/Application Support/Gimp' to a possibly shared location of the help files elsewhere) are not recognized and a copy of the files is installed nevertheless.

[1] (at least last time I checked - haven't (re-)installed the help files recently because there has been no update for 10.5.8 Leopard yet)