sil osx setgid enabled

[saarn]

The OsX download for Sil has setgid enabled as an xattr on at least one of the files-- this makes the application ask for an admin password when you go to open a save file. I was able to work around by doing chmod -R ug-s * in the sil directory, but this should probably be cleaned up.

[half]

The OsX download for Sil has setgid enabled as an xattr on at least one of the files-- this makes the application ask for an admin password when you go to open a save file. I was able to work around by doing chmod -R ug-s * in the sil directory, but this should probably be cleaned up.

I'd love to fix this as it is a long-standing bug. Any ideas which file or directory is acting up? I tried:

ls -R -@ -l lib

I found:

com.apple.TextEncoding
com.apple.metadata:kMDItemWhereFroms
com.apple.FinderInfo
com.apple.quarantine

but no setgid. Could it be the .quarantine instead? This is something Apple uses on executables before the user launches them the first time and might be triggering the warning (a bit odd as it is only present on some images and fonts that I inherited from NPP). This is compatible with your evidence as the confirmation dialogue doesn't appear every time. The only other thing I know is that the dialogue doesn't appear at launch, but seems to come up when I am selecting a savefile.

[saarn]

i think you're looking in the wrong directory -- I ran the chmod fix on Sil.app not lib.

[half]

i think you're looking in the wrong directory -- I ran the chmod fix on Sil.app not lib.

Ah, I hadn't looked inside Sil.app, but I still didn't find any setgid bits or strange xattrs (only com.apple.FinderInfo and com.apple.ResourceFork).

I haven't had any password requests in the last 10 times I've tried opening a savegame though, so perhaps removing the quarantines has fixed it. I'm open to other ideas too.

[half]

(And thanks for the help -- it is very much appreciated!)

[debo]

I haven't had any password requests in the last 10 times I've tried opening a savegame though, so perhaps removing the quarantines has fixed it. I'm open to other ideas too.

Might be keychain or some other authorization proxy -- I was asked for a system password the first time I opened a Sil 1.0.2 savegame, but it never asked me again after that, and I haven't messed with the files in the distribution at all.

[saarn]

I guess it's completely possible that me chmodding everything did nothing and that the real difference was just running again after Sil crashed when I closed the password dialog.

I feel like there really ought to be some sort of way to catch this using a debugger, but I'm not terribly familiar with everything Xcode provides.

[half]

Well, I've had the dialogue come up again after 10 to 15 tries at different times, so it doesn't look like my work so far has solved the problem. I'm guessing that the same is true of the chmod approach, since I couldn't find a file that the approach would actually modify. The inconsistency of this dialogue does indeed make it harder to catch. I have no idea how to find this with X Code unfortunately.

[half]

I had the dialogue come up again and decided to read it carefully and find out as much as I could from it. It turns out it needs permissions called:

system.privilege.setugid_appkit

Which is probably what you saw before trying the chmod to get rid of a setgid bit. My current theory is that this is being triggered by calls to the function safe_setuid_grab() which occur on save and load and some other places. I'm not completely sure though.

One thing I do know is that on the Carbon port I'm using, SET_UID is defined, so some of the following code does get run.

/*
 * Hack -- grab permissions
 */
void safe_setuid_grab(void)
{

#ifdef SET_UID

# ifdef SAFE_SETUID

#  ifdef HAVE_SETEGID

	if (setegid(player_egid) != 0)
	{
		quit("setegid(): cannot set permissions correctly!");
	}

#  else /* HAVE_SETEGID */

#   ifdef SAFE_SETUID_POSIX

	if (setgid(player_egid) != 0)
	{
		quit("setgid(): cannot set permissions correctly!");
	}

#   else /* SAFE_SETUID_POSIX */

	if (setregid(getegid(), getgid()) != 0)
	{
		quit("setregid(): cannot set permissions correctly!");
	}

#   endif /* SAFE_SETUID_POSIX */

#  endif /* HAVE_SETEGID */

# endif /* SAFE_SETUID */

#endif /* SET_UID */

}

[myshkin]

I had the dialogue come up again and decided to read it carefully and find out as much as I could from it. It turns out it needs permissions called:

system.privilege.setugid_appkit

Which is probably what you saw before trying the chmod to get rid of a setgid bit. My current theory is that this is being triggered by calls to the function safe_setuid_grab() which occur on save and load and some other places. I'm not completely sure though.

See the "setuid/setgid apps disallowed" paragraph of the "Notes specific to MacOS X 10.6" section of the Cocoa Application Framework Release Notes. Are you running Snow Leopard or later?

The file to check ought to be Sil.app/Contents/MacOS/sil. As far as I can tell, the zip on the website does not make that executable setgid, nor does Makefile.osx's install target make it setgid, and so the behavior described in the release notes should not occur.

Are you seeing this behavior with V?

[saarn]

I'm running snow leopard, haven't seen the issue with v4-- it's been a long time since I've played pure V.

[half]

I'm also running Snow Leopard (10.6) and don't play V.

The file path you mention is indeed the one that the dialogue box says is responsible, but to the best of my understanding, it also doesn't have the setgid bit set. "ls -l" gives me:

-rwxr-xr-x  1 half  staff  1092876 11 Jul 23:13 sil

It may well be that when I move to the Cocoa main file (to get the Shockbolt graphics) the problem goes away, so there is no need to work too hard on this one.