From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <28570e6dcb9cc8b12ff580a83deebb91@caldo.demon.co.uk>
To: 9fans@cse.psu.edu
From: forsyth@caldo.demon.co.uk
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: [9fans] /adm/users
Date: Fri, 31 May 2002 21:07:52 +0100
Topicbox-Message-UUID: a3248148-eaca-11e9-9e20-41e7f4b1d025

take care that /adm/users is always owned by adm, for both disk/kfs and The file server.
otherwise, it will deadlock trying to cmd_exec("user") [cmd_exec("users")],
which it does at start up,
because that command wlocks the uid/gid information before accessing /adm/users,
and sub.c:/^iaccess has changed the order of the checks from previous versions,
so that whereas before it checked other permission first, it
now checks ownership first, and if that's not right, calls ingroup, which rlocks
the uid/gid data (oh dear!).  at the moment, you'll need a distinct, functioning plan 9 machine to
build a special variant of disk/kfs and 9pcfs to bypass the check (in different ways)
long enough to chown it (in allow mode) back to adm.
in my case it was just an auxiliary file system for CD contents, so it was easier to mend.
of course, i was approaching a deadline so it made perfect sense that i was hit by it now.