Thank you to all who replied.  I am, you probably guessed, a bit of
a RH virgin and didn't know about the heavy patching applied to
kernels -- I'm from the Debian world where a range of kernels is always
available and trying them out is just an apt-get away. Please excuse
my faux pas.

Following your advice I've searched around the RH site and found
the most recent kernels I could, I've tested

  2.6.18-181.el5
  2.6.18-175.el5.jtltest.96
  2.6.18-164.6.1.el5
  2.6.18-128.7.1.el5
  2.6.18-53.1.4.el5

behavior is identical for all of them:

/home is nfs4 automounted, authentication is kerberos
over LDAP.

  > ls -l /home
  drwx------ 2 user1 user1    72 Dec 16 16:51 user1
  drwxrwx--- 2 user2 userall  72 Dec 16 16:51 user2

  > ls -l /home/user2
  rw-rw----    user2 userall 0  Dec 17 11:33 group-writable

login as user1

  > groups
  user1 userall

  > pwd
  /home/user1

  > echo "time to die" > ../user2/group-writable

-> kernel panic

gss_wrap_req [auth_rpcgss]
cache_alloc_refill
gss_wrap_req [auth_rpcgss]
nfs4_xdr_enc_write [nfs]
rpcauth_wrap_req [sunrpc]
nfs4_xdr_enc_write [nfs]
call_transmit [sunrpc]
__rpc_execute [sunrpc]
nfs_execute_write [nfs]
nfs_flush_one [nfs]
nfs_flush_list [nfs]
nfs_flush_one [nfs]
nfs_sync_inode_wait [nfs]
nfs_do_fsync [nfs]
nfs_file_flush [nfs]
filp_close
sys_dup2
syscal_call
EIP kunmap_atomic
kernel panic -- not syncing: Fatal exception

Bizzarely, puting the killer command into a script
(just to save time) means no kernel panic, I ran the
script many times.

Garrett Holmstrom:
> The right way to fix this problem would be to file a bug against the
> kernel package so upstream can backport a fix.  They add bugfixes
> and new features by patching the same kernel version so the release
> can keep the same version throughout its lifetime while still remaining
> useful.

I'll do that, but do you mean the kernel devs at kernel.org
or RH or SL?

Cheers, and thanks again for all the help

Jim