I'm still fighting this problem. What version of X11 did you update to,
chambers?
* * *
I checked some other settings and tried some other experiments.
1. In X11 we get the bash-3.2 shell, with a path of /usr/bin /bin /usr/sbin /sbin.
2. The command
in an X11 shell launches and immediately quits Gimp, just as launching from the Finder does.
3. If I log in as a brand new user (not having used the Mac before), the Gimp problem still occurs.
4. Leopard Server manages preferences for these computers, so I tried releasing a Mac from managed preferences. I'm not sure if I really untangled all dependencies on the server, but the Mac still had the same problem with Gimp.
5. Running fs_usage showed that the process is accessing some "interesting" files. Among them is file /Applications/Gimp.app/Contents/Resources/etc/dbus-1/session.conf, whose contents are this:
Code:
<!-- This configuration file controls the per-user-login-session message bus.
Add a session-local.conf and edit that rather than changing this
file directly. -->
<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
<!-- Our well-known bus type, don't change this -->
<type>session</type>
<listen>unix:tmpdir=/tmp</listen>
<standard_session_servicedirs />
<policy context="default">
<!-- Allow everything to be sent -->
<allow send_destination="*" eavesdrop="true"/>
<!-- Allow everything to be received -->
<allow eavesdrop="true"/>
<!-- Allow anyone to own anything -->
<allow own="*"/>
</policy>
<!-- Config files are placed here that among other things,
further restrict the above policy for specific services. -->
<includedir>session.d</includedir>
<!-- This is included last so local configuration can override what's
in this standard file -->
<include ignore_missing="yes">session-local.conf</include>
<include if_selinux_enabled="yes" selinux_root_relative="yes">contexts/dbus_contexts</include>
<!-- For the session bus, override the default relatively-low limits
with essentially infinite limits, since the bus is just running
as the user anyway, using up bus resources is not something we need
to worry about. In some cases, we do set the limits lower than
"all available memory" if exceeding the limit is almost certainly a bug,
having the bus enforce a limit is nicer than a huge memory leak. But the
intent is that these limits should never be hit. -->
<!-- the memory limits are 1G instead of say 4G because they can't exceed 32-bit signed int max -->
<limit name="max_incoming_bytes">1000000000</limit>
<limit name="max_outgoing_bytes">1000000000</limit>
<limit name="max_message_size">1000000000</limit>
<limit name="service_start_timeout">120000</limit>
<limit name="auth_timeout">240000</limit>
<limit name="max_completed_connections">100000</limit>
<limit name="max_incomplete_connections">10000</limit>
<limit name="max_connections_per_user">100000</limit>
<limit name="max_pending_service_starts">10000</limit>
<limit name="max_names_per_connection">50000</limit>
<limit name="max_match_rules_per_connection">50000</limit>
<limit name="max_replies_per_connection">50000</limit>
<limit name="reply_timeout">300000</limit>
</busconfig>
File session.conf has a companion file /Applications/Gimp.app/Contents/Resources/etc/dbus-1/system.conf, whose contents are this:
Code:
<!-- This configuration file controls the systemwide message bus.
Add a system-local.conf and edit that rather than changing this
file directly. -->
<!-- Note that there are any number of ways you can hose yourself
security-wise by screwing up this file; in particular, you
probably don't want to listen on any more addresses, add any more
auth mechanisms, run as a different user, etc. -->
<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
<!-- Our well-known bus type, do not change this -->
<type>system</type>
<!-- Run as special user -->
<user>messagebus</user>
<!-- Fork into daemon mode -->
<fork/>
<!-- We use system service launching using a helper -->
<standard_system_servicedirs/>
<!-- This is a setuid helper that is used to launch system services -->
<servicehelper>/tmp/skl/Gimp.app/Contents/Resources/libexec/dbus-daemon-launch-helper</servicehelper>
<!-- Write a pid file -->
<pidfile>/tmp/skl/Gimp.app/Contents/Resources/var/run/dbus/pid</pidfile>
<!-- Only allow socket-credentials-based authentication -->
<auth>EXTERNAL</auth>
<!-- Only listen on a local socket. (abstract=/path/to/socket
means use abstract namespace, don't really create filesystem
file; only Linux supports this. Use path=/whatever on other
systems.) -->
<listen>unix:path=/tmp/skl/Gimp.app/Contents/Resources/var/run/dbus/system_bus_socket</listen>
<policy context="default">
<!-- Deny everything then punch holes -->
<deny send_interface="*"/>
<deny receive_interface="*"/>
<deny own="*"/>
<!-- But allow all users to connect -->
<allow user="*"/>
<!-- Allow anyone to talk to the message bus -->
<!-- FIXME I think currently these allow rules are always implicit
even if they aren't in here -->
<allow send_destination="org.freedesktop.DBus"/>
<allow receive_sender="org.freedesktop.DBus"/>
<!-- valid replies are always allowed -->
<allow send_requested_reply="true"/>
<allow receive_requested_reply="true"/>
</policy>
<!-- Config files are placed here that among other things, punch
holes in the above policy for specific services. -->
<includedir>system.d</includedir>
<!-- This is included last so local configuration can override what's
in this standard file -->
<include ignore_missing="yes">system-local.conf</include>
<include if_selinux_enabled="yes" selinux_root_relative="yes">contexts/dbus_contexts</include>
</busconfig>
File system.conf contains references to three files under /tmp/skl/Gimp.app/Contents/Resources/:
- libexec/dbus-daemon-launch-helper ("a setuid helper used to launch system services")
- var/run/dbus/pid (for the process ID)
- var/run/dbus/system_bus_socket (local socket)
So this /tmp folder seems to have a direct role. My best guess is that our use of network-defined users is somehow involved, and that we have some kind of permissions problem.
Meanwhile, 3 Macs in the classroom now have this problem, so something happens to "break" a Mac's copy of Gimp while a student (non-admin account) is using it.
