Troubleshooting

[ElectricPaladin]

So, here I am on my Mac, running OSX, when my copy of Angband v3.0.6 suddenly decides to start giving me the message: "Cannot create the '/var/root/Library/Preferences/Angband/scores/scores.raw' file! The lib directory is probably missing or broken. Perhaps the archive was not extracted correctly. See the 'readme.txt' file for more information."

So I mess around for a while. I restart a few times. I'm not, by the way, very good at this. Anyway, I can't fix it. So, I kidnap my favorite save file, dump everything else Angband related I can find into the trash, and try to re-download it.

And it still doesn't work!

So, does anyone know how to make my Angband work? I've even found a more recent version (v3.0.9), and it still isn't helping.

By the way, I registered with these forums for the initial reason of working this out, so please don't fail me!

[Nick]

I'm really guessing here (and hopefully someone with some actual knowledge will give a better answer), but it looks to me like something else has changed with your system that is stopping that file from being written. If you have changed anything else recently, that might give some clues.

[zaimoni]

Agreed: it's obviously a file permissions error (Angband lost its authority to write the file in the first place). As OSX is a *NIX and doing a clean install of V3.0.9 didn't work, I'd say either that Angband is not running as the user the installer runs as, or the installer is not giving said user write permissions to its own directories. As a recent change that the OP hadn't figured out already, it probably was a side effect of a patch or recentlly installed application.

In any case, making the relevant directories world-writeable will bypass this (insecurely), assuming that the caveat about Mac9 and lower having nonunique filepaths doesn't hold for OSX.

Windows Vista has this problem as well. (Can't install to Program Files subdirectory because Angband isn't guaranteed to be able to write to where it's installed; have to unpack/build archive as the login who's going to play it).

[ElectricPaladin]

Another event, if it helps.

So, I downloaded Zangband, thinking maybe it would work, and also that it was a version I'd been wanting to play, and it didn't work either. BUT, when I downloaded Steamband (a weird, weird version, by the way), it worked just fine.

Is there anyone out there who is enough of a Mac computer person that they can walk me through giving Angband the permissions it needs? I'd rather not make my hard drive world-writeable if I can avoid it.

[roustk]

/var/root is the home directory for root (superuser) and shouldn't be readable by other users. It looks like Angband was installed by root, and thus is putting the score file there.

By comparison, I installed Angband as myself (not root), by dragging-and-dropping the application bundle into /Applications/. This resulted in my scores directory (and save, data, and bone) being created in /Users/roustk/Library/Preferences/Angband/.

Why did this suddenly become a problem? I would guess that you either (1) installed a new security update or version of the OS or (2) ran "fix permissions" from DiskUtility.

Angband doesn't keep any "preference" file telling it where its directories are stored, so the fact that the ~root/Library/Preferences/Angband stuff exists shouldn't be causing problems with a new installation. (Angband's file locations are fixed by the PRIVATE_USER_PATH variable at compile time -- either all directories are in a central application under Angband.app on MacOS X or most directories are there but some, like scores and save, are under ~/Library/Preferences/Angband/.)

Suggestions for a fix:
1) If you are compiling Angband yourself, do it as yourself, not as root. You may also want to use sudo and delete /var/root/Library/Preferences/Angband.

2) If you are installing from the pre-compiled dmg, just drag-and-drop the application while logged in as yourself.

3) If all else fails, you can brutally change the permissions on the directory in /var/root. We will isolate the access to just the Angband directory, but it probably is still a possible security hole that may get 'fixed' again. Changing permissions is easy, especially if you've ever used Terminal (or unix) before:
a) Open Terminal. It should be in either /Applications or /Applications/Utilities.
b) Enter the following command:

sudo chmod -R ugo+rwX /var/root/Library/Preferences/Angband

EDIT: note that capitalization is vitally important here. Make absolutely sure that the '-R' and 'X' are capitalized while the rest of 'ugo+rw' is lower case./EDIT
c) Enter your login password when asked. (If you've never used sudo, you'll get a lecture about trust.)
d) Type "logout" (no quotes).
e) Close the window and quit terminal.

(Explanation: Terminal allows a command-line interface to the unix system behind OSX, 'sudo' runs the command as superuser, 'chmod' changes read/write permissions, '-R' makes chmod affect sub-directories, 'ugo+rwX' means to add permission for everybody (user, group, and other) to read and write files and read, write, or execute (access) directories.)

Kevin

[takkaria]

So, does anyone know how to make my Angband work? I've even found a more recent version (v3.0.9), and it still isn't helping.

By the way, I registered with these forums for the initial reason of working this out, so please don't fail me!

Are you running the game from Quicksilver or any other app launcher?

(This was also reported on http://dev.rephial.org/trac/ticket/384. Given I don't have a Mac yet, I can't really help out on this issue so well...)

[ElectricPaladin]

Nope. No app launcher.

[roustk]

EDIT: This dives deeply into the code. Skip as needed./EDIT

(This was also reported on http://dev.rephial.org/trac/ticket/384. Given I don't have a Mac yet, I can't really help out on this issue so well...)

I'm usually pretty good with unix, but the code in z-file.c gets fairly deep. Looking at 3.0.9 because that's what I have on my laptop.

Makefile.osx sets -DPRIVATE_USER_PATH=\"~/Library/Preferences\" -DUSE_PRIVATE_PATHS
and ultimately SET_UID (through h-basic.h). This means that init2.c calls the first version of path_parse() in z-file.c like this:

        path_parse(dirpath, sizeof(dirpath), PRIVATE_USER_PATH);

If I am following everything correctly, we have internal variables set as follows:

file=(char *)"~/Library/Preferences"
u=file+1
s=u
user[0]='\0'
u=user
u=getlogin()

On my 10.4 machine, launching Angband through the GUI means that it isn't bound to a terminal, so getlogin() will fail and u is a null pointer, so the path is determined from

pw=getpwuid(getuid())

getuid() is supposed to never fail to return the uid for the process, but if it did fail it would likely return 0 -- root. I would be tempted to say that if getuid()==0, we have an error and should quit.

As the code has already tried the only two ways to identify the user, we are stuck for a good way to figure out who he really is. I can think of three potential workarounds, all with significant drawbacks:
1) On an essentially single-user system, we might be able to make a good guess by using getutxent() to identify who is logged in on console. This code would likely be ugly, and the assumption would be obviously false on a multiuser system. Limiting it to Macs (and maybe non-Server Macs) might work.
2) We could ask the user to type in their username. This code might be easy enough, but error checking could be a nightmare.
3) We could fall back on the centralized directory structure (not USE_PRIVATE_PATHS). If the failure to identify the user is transitory, this is an unimaginably bad solution. If the user doesn't have write permission to the central directory (inside the application, on Macs), this will also fail.

Kevin

[roustk]

So I mess around for a while. I restart a few times. I'm not, by the way, very good at this. Anyway, I can't fix it. So, I kidnap my favorite save file, dump everything else Angband related I can find into the trash, and try to re-download it.

To double-check -- your savefile was in ~/Library/Preferences/Angband/save, right?

(That is, under your home directory, in Library, in Preferences, in Angband, in save.)

Nope. No app launcher.

Just for kicks, can you open a terminal and run the following command, while Angband is running?

ps -axcj

I'm looking for the line with "angband" on the right side, like below. It is likely the last entry with '??' in the TT column.

[roustk-mac:~] roustk% open /Applications/Angband.app/
[roustk-mac:~] roustk% ps -axcj
USER       PID  PPID  PGID   SESS JOBC STAT  TT       TIME COMMAND
root         1     0     1 24a8e88    0 S<s   ??    0:01.78 launchd
...
roustk     754    77    77 24a77e4    0 S     ??    0:06.93 angband
...
[roustk-mac:~] roustk%

What this will tell us is who the computer thinks is running angband (roustk) and the terminal it is associated with (?? -- none).

Kevin

[ElectricPaladin]

Yes, that is where I found the save file.

So, when I enter "ps -axcj" into the Terminal, I discover that my computer thinks 'mark' (that's me) is running Angband.

[ElectricPaladin]

Also, I tried: "sudo chmod -R ugo+rwX /var/root/Library/Preferences/Angband", and the terminal said it didn't know what var/root/Library/Preferences/Angband" is.

[roustk]

Also, I tried: "sudo chmod -R ugo+rwX /var/root/Library/Preferences/Angband", and the terminal said it didn't know what var/root/Library/Preferences/Angband" is.

I would actually interpret this as a good thing -- it means that Angband never managed to create those directories, and thus never actually had root privileges.

Given your other post, we still need to figure out why it is unable to identify the user for the process, when ps has no trouble.

Since ps knows the correct user, we know (among other things) Angband has a non-zero uid, that uid exists in the /etc/passwd equivalent, and that uid belongs to you. ps should be doing something similar to the getpwuid(getuid()) trick that Angband uses, but I'll try to hunt down exactly what code it uses...
Looking at the 10.4.10 Darwin sources, ps ultimately calls getpwuid using a uid it reads directly from the credentials of the process (struct ucred.cr_uid) -- in short, this is the same method, but it fails for Angband while succeeding for ps.

Things are a bit pear-shaped.

Kevin

[roustk]

Also, I tried: "sudo chmod -R ugo+rwX /var/root/Library/Preferences/Angband", and the terminal said it didn't know what var/root/Library/Preferences/Angband" is.

Since I haven't happened on a good and proper fix for this, and can't yet explain why things are failing, you could consider working around the problem by *creating* the missing directory structure. This almost certainly opens a security hole allowing escalation of privileges, but it is fairly obscure (to exploit it there would have to be a program running with root permissions that would read and react to the contents of ~root/Library/Preferences/Angband). Note carefully that this does not "fix" the problem; it merely papers over the issue, but you'll be able to keep playing.

If there are multiple users of your machine, do not do this -- we are in effect limiting Angband exclusively to your account.

What we will do is create a symbolic link (like a shortcut) that tells the computer that /var/root/Library/Preferences/Angband is actually /Users/<you>/Library/Preferences/Angband. This will take 3 commands in the Terminal, although the second of them takes two lines. (Note: don't put anything, even a space, after the "\" -- it must be the last thing on that line.)

sudo ls ~root/Library/Preferences/Angband

sudo ln -s ~/Library/Preferences/Angband \
  ~root/Library/Preferences/Angband

sudo ls -ld ~root/Library/Preferences/Angband

Run the commands one by one, to make sure that they run correctly.
1) The first command (ls) should prompt you for your login password and then must tell you that /var/root/Library/Preferences/Angband does not exist.
2) The second command (ln -s) creates a symlink named ~root/Library/Preferences/Angband pointing to ~/Library/Preferences/Angband. (The "\" means to read the next line too.)
3) The third command (ls -ld) checks that the symlink was created correctly. This needs to be run as superuser (sudo) because the permissions on ~root/Library and ~root/Library/Preferences should be too restrictive to allow general users to even view the directories (mode 700 to unix geeks).

You should see something like this (I've reformatted slightly for clarity):

[roustk-mac:~] roustk% sudo ls ~root/Library/Preferences/Angband
Password:
ls: /var/root/Library/Preferences/Angband: No such file or directory
[roustk-mac:~] roustk% sudo ln -s ~/Library/Preferences/Angband \
?    ~root/Library/Preferences/Angband
[roustk-mac:~] roustk% sudo ls -ld ~root/Library/Preferences/Angband
lrwxr-xr-x   1 root  wheel  41 Jan 23 11:04 
    /var/root/Library/Preferences/Angband 
    -> /Users/roustk/Library/Preferences/Angband
[roustk-mac:~] roustk%

It is possible that the ln -s command will fail -- perhaps ~root/Library/Preferences itself does not exist on a typical OSX installation. (However, mine is a fairly fresh re-install of 10.4 and I've only logged in as root via su, not on console or in the GUI since the re-install, so I expect that everybody has this much of a ~root directory.) If ln -s fails, I would probably recommend just giving up -- fixing it will require opening a much bigger security hole.


Assuming that everything works correctly, give Angband a try again. It may continue to fail (due to the tight permissions on ~root), but you may be okay. If Angband still fails, you should undo the link and wait for further instruction. Please post the result of the ls -ld command above if this happens (technical: if either your or root's umask is other than 22, there is an easy fix).

Undo the link with: sudo rm ~root/Library/Preferences/Angband

Unix gurus -- I want a second opinion on a further fix, if his Angband continues to fail. I'm reasonably confident that under old unices (particularly HP-UX 9) you could follow a symlink contained in a 700 directory even if you were in group or other. However, that seems like a security hole that should have been fixed in the intervening 15 years. I fear that, for Angband to use a symlink in ~root/Library/Preferences, we're going to need to set ~root, Library, and Preferences to mode 701. We shouldn't need 704 or 705, so we would still have obscurity, if not security.

Since I cannot replicate his Angband problem, I can't test this by experimentation on my own machine. But educated guesses would be clarifying.

Kevin

[roustk]

(This was also reported on http://dev.rephial.org/trac/ticket/384. Given I don't have a Mac yet, I can't really help out on this issue so well...)

I've updated that ticket with some of my findings so far. I identify where the failure has to be (z-file.c). I also provide some example code for an executable to identify who owns the file itself. The nasty part is finding the file without using either argv or the working path, because I didn't want to trust those deep in the bowels of a program.

The owner of the executable might be a decent approximation of the true user, on a single-user system (like many Macs).

Kevin

[zaimoni]

This is a known bug as of Nov 13 2006:

http://lists.apple.com/archives/cocoa-dev/2006/Nov/msg00618.html

MacOS APIs were reported to be immune to this, so they could be used as a workaround.