We are running Solaris 8 on a Sunfire 6800. I have successfully compiled and installed Openssh 4.2p1, it works but everytime a user uses ssh command we get a strange message in /var/adm/messages, originated from limdaemon (system resource manager) example: [scrdux22] /var/adm > grep sshd messages | tail Jan 3 15:38:39 scrdux22 limdaemon: [ID 347701 daemon.error] Message from pid 26 563, lnode sshd: lnode attach failed in setuid Jan 3 15:39:18 scrdux22 limdaemon: [ID 348742 daemon.error] Message from pid 26 775, lnode sshd: lnode attach failed in setuid Jan 3 15:40:28 scrdux22 limdaemon: [ID 988006 daemon.error] Message from pid 27 085, lnode sshd: lnode attach failed in setuid Jan 3 15:49:38 scrdux22 limdaemon: [ID 210649 daemon.error] Message from pid 29 299, lnode sshd: lnode attach failed in setuid /opt/OBSDssh/bin/ssh -V OpenSSH_4.2p1, OpenSSL 0.9.8a 11 Oct 2005 [scrdux22] /var/adm > uname -a SunOS scrdux22 5.8 Generic_117350-25 sun4u sparc SUNW,Sun-Fire config string: $ ./configure --prefix=/opt/OBSDssh --with-pam --without-rsh --sysconfdir=/etc --with-ssl-dir=/usr/local/ssl
The message if from limdaemon not sshd. Google finds this: http://docs.sun.com/app/docs/doc/816-7751/6mdo2so14?a=view [quote] lnode attach failed in setuid If the Solaris Resource Manager software is installed and enabled, then the setuid system call, in addition to its standard function, attaches the calling process to the lnode associated with its new real UID. If attachment fails, it is usually because there is no lnode associated with the new UID. [/quote] It sounds like you need to associate an lnode with the UID in question (whatever that means; I (and sshd) know nothing of lnodes).
For those wondering (as I was) what the heck an "lnode" is, from Chapter 5 of the URL above: [quote] The Solaris Resource Manager system is built around a fundamental addition to the kernel: a per-user structure called an lnode. An lnode is essentially a fixed-size place in which many kinds of per-user data can be stored and updated. For every unique UID defined in the password map, there should be a corresponding lnode. (This refers to every unique UID returned by successive getpwent(3C)calls.) An lnode may exist without a corresponding password map entry, but this is not recommended. Lnodes are stored on disk and automatically moved in and out of memory by the kernel. In-memory copies of lnodes that have been changed since they were read from disk are written back as part of the regular system synchronization operations, as well as on demand when the sync command is run, or when necessary to free space in the lnode cache for reading in further lnodes. Lnodes are maintained as a tree hierarchy, with the central system administrator as the head of the tree, and other users as group headers of smaller groups of users within the tree. The central administrator is the superuser, or root user of the system. [/quote] It sounds like a local system configuration/administration issue, not a bug in in sshd.
Since this appears to be a system configuration issue not a problem with sshd itself I am closing this bug. Please reopen if you have any further information that points to sshd doing something wrong.
Change all RESOLVED bug to CLOSED with the exception of the ones fixed post-4.4.