Bug 158187 - in.rexecd fails with rexec: Illegal seek
Summary: in.rexecd fails with rexec: Illegal seek
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: rsh
Version: 3.0
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Karel Zak
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-05-19 13:59 UTC by John Sopko
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-05-20 13:47:47 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description John Sopko 2005-05-19 13:59:25 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050319

Description of problem:
Just updated to the latest rsh-server package to fix bug 118630 related to
rexec. The in.rexecd seems to be broke. The client now works to the last
in.rexecd release (rsh-server-0.17-17) without the "-a" option. But
the new server gives the following error when trying to connect to it:

# new rexec client to previous in.rexecd version works:

sopko@lark:3% rexec swan date
Password: 
Thu May 19 09:49:59 EDT 2005

# new rexec client to new in.rexecd server:

sopko@lark:4% rexec lark date
Password: 
lark.cs.unc.edu: No such file or directory
rexec: Error in rexec system call,
rexec: (The following system error may itself be in error)
rexec: Illegal seek

Version-Release number of selected component (if applicable):
rsh-server-0.17-17.6

How reproducible:
Always

Steps to Reproduce:
1. enable in.rexecd in /etc/xinetd.c/rexec
2. try an rexec command to the server
3.
  

Actual Results:  sopko@lark:4% rexec lark date
Password: 
lark.cs.unc.edu: No such file or directory
rexec: Error in rexec system call,
rexec: (The following system error may itself be in error)
rexec: Illegal seek

Expected Results:  Command should execute without an error

Additional info:

Tried to start in.rexecd with -D option and did not help

sopko@lark:18% cat /etc/xinetd.d/rexec 
# default: off
# description: Rexecd is the server for the rexec(3) routine.  The server \
#       provides remote execution facilities with authentication based \
#       on user names and passwords.
service exec
{
        socket_type             = stream
        wait                    = no
        user                    = root
        log_on_success          += USERID
        log_on_failure          += USERID
        server                  = /usr/sbin/in.rexecd -D
        disable                 = no
}

Comment 1 Karel Zak 2005-05-19 16:26:46 UTC
man xinetd.conf(5):

 server        determines the program to execute for this service.

 server_args   determines the arguments passed to the server. In contrast  to  
               inetd,  the  server  name should not be included in server_args.

You should use:

service exec
{
        socket_type             = stream
        wait                    = no
        user                    = root
        log_on_success          += USERID
        log_on_failure          += USERID
        server                  = /usr/sbin/in.rexecd
        server_args             = -D
        disable                 = no
}

Please, can try strace rexecd on server if your problem don't disapper? The
instructions [section IV. Troubles]:

http://people.redhat.com/kzak/docs/rsh-rlogin-howto.html

Comment 2 John Sopko 2005-05-19 17:06:57 UTC
I tried to do the strace according to the web page instructions,
the strace works but does not complete and does not show what the
problem might be. It hangs when I rexec into the machine. I removed
/etc/xinet.d/rexec and tried to start in.rexecd by hand but it
complains:

lark/root [/usr/sbin] # /usr/sbin/in.rexecd
rexecd: getpeername: Socket operation on non-socket

so I could not do an strace on it directly.

I tried using:

server_args             = -D

in xinetd.d/rexec and this did not help.

I copied /usr/sbin/in.rexecd from another machine that had the
previous version and it works fine! So there is no problem with the
configuration on the machine that is failing with the new in.rexecd,
it is definetly in the new in.rexecd!

Using the previous in.rexecd works:

sopko@lark:22% rexec lark date
Password: 
Thu May 19 13:03:54 EDT 2005

Moving the new one back in place fails:

lark/root [/usr/sbin] # ls -l in.rexecd*
-rwxr-xr-x    1 root     root         7836 May 19 12:55 in.rexecd
-rwxr-xr-x    1 root     root         8136 Feb  2 07:50 in.rexecd.new
-rwxr-xr-x    1 root     root         7836 May 19 13:05 in.rexecd.previous
lark/root [/usr/sbin] # /bin/cp in.rexecd.new in.rexecd

sopko@lark:23% rexec lark date
Password: 
lark.cs.unc.edu: No such file or directory
rexec: Error in rexec system call,
rexec: (The following system error may itself be in error)
rexec: Illegal seek





Does it work for you?



Comment 3 Karel Zak 2005-05-20 11:35:48 UTC
Hmm.. nice regression. The last version that works fine is rsh-0.17-17, right?
BTW, the option "-D" is new in RHEL3-U5.

Comment 4 John Sopko 2005-05-20 11:44:58 UTC
rsh-server-0.17-17, is the last release that seems to work.
rsh-server contains in.rexecd. rsh-0.17-17 is the client
that contains the rexec client command. The latest
rsh-0.17-17.6 fixes the bug where you had to specify
the -a option. The rsh-0.17-17.6 rexec client works fine
to the previous rsh-server-0.17-17 in.rexecd server.

I know rexec is antiquated but we have lots of Windows users
connecting to linux servers via Xwin32, (an X server on windows).
They use rexec to launch applications back to the X server.

I am migrating them to connect via ssh but it will take some time
Since we need to upgrade their Windows machines to the latest
Xwin32 X server that supports ssh connections.

I eventually see rexec going away, but for now it would be nice
to have it work at least as good as it did.

Comment 5 Karel Zak 2005-05-20 12:56:05 UTC
Please, can you 
  - check /var/log/messages and /var/log/secure
  - send me /etc/pam.d/rexec
  - and "rpm -q pam glibc"

everything from server side of course. Thanks.

Comment 6 John Sopko 2005-05-20 13:47:47 UTC
We run AFS so in pam most modules like pam.d/rexec reference
pam.d/system-auth.  It does appear to be some sort of auth issue, if
I give a wrong passwd to the working in.rexecd I get the same error
as when giving a good passwd to the latest non working in.rexecd. The
messages/secure logs appear to show no problem though.

The previous working in.rexecd does not show as much verbose
messages. Note I updated the non working system to rhel-update 5 and
this updates some pam libs.

Non working in.rexecd logs:

/var/log/messages:

May 20 09:31:24 lark in.rexecd[22793]: connect from lark.cs.unc.edu
May 20 09:31:24 lark PAM_pwdb[22793]: (rexec) session opened for user sopko by
(uid=0)
May 20 09:31:24 lark PAM_pwdb[22793]: (rexec) session closed for user sopko
May 20 09:31:24 lark pam_afs[22793]: AFS Session closed

/var/log/secure:

May 20 09:32:09 lark xinetd[7880]: START: exec pid=22807 from=152.2.129.13
May 20 09:32:09 lark xinetd[7880]: START: auth pid=22808 from=152.2.129.13
May 20 09:32:09 lark xinetd[22807]: USERID: exec OTHER
:[U2FsdGVkX1+lkepRT/YzNpKJPAshD6vTvy2sqLe6kaI=]

Previous working in.rexecd logs:

/var/log/messages:

May 20 09:39:22 swan in.rexecd[14593]: connect from lark.cs.unc.edu
May 20 09:39:22 swan in.rexecd: login from lark.cs.unc.edu as sopko

/var/log/secure:

May 20 09:40:22 swan xinetd[1603]: START: exec pid=14724 from=152.2.129.13
May 20 09:40:22 swan xinetd[14724]: USERID: exec OTHER
:[U2FsdGVkX18S5WRh0Ka/mbYvgBLFgF7UvmLQNlCqQjI=]


When entering a bad passwd here is what happens:

Non working in.rexecd logs:

/var/log/messages:

May 20 09:40:48 lark in.rexecd[22902]: connect from lark.cs.unc.edu
May 20 09:40:48 lark pam_afs[22904]: AFS Authentication failed for user sopko.
password was incorrect 
May 20 09:40:48 lark PAM_pwdb[22902]: authentication failure; (uid=0) -> sopko
for rexec service

/var/log/secure:

May 20 09:42:02 lark xinetd[7880]: START: exec pid=22910 from=152.2.129.13
May 20 09:42:02 lark xinetd[7880]: START: auth pid=22911 from=152.2.129.13
May 20 09:42:02 lark xinetd[22910]: USERID: exec OTHER
:[U2FsdGVkX1/+vzOv7ldQMRs+pbxOktN5RT16YGclz50=]

Previous working in.rexecd logs:

/var/log/messages:

May 20 09:43:18 swan in.rexecd[14814]: connect from lark.cs.unc.edu
May 20 09:43:18 swan pam_afs[14815]: AFS Authentication failed for user sopko.
password was incorrect 
May 20 09:43:18 swan PAM_pwdb[14814]: authentication failure; (uid=0) -> sopko
for rexec service


Here are the PAM files:

lark/root [/etc/pam.d] # pwd
/etc/pam.d
lark/root [/etc/pam.d] # cat rexec
#%PAM-1.0
# For root login to succeed here with pam_securetty, "rexec" must be
# listed in /etc/securetty.
auth       required     pam_nologin.so
auth       required     pam_securetty.so
auth       required     pam_env.so
auth       required     pam_stack.so service=system-auth
account    required     pam_stack.so service=system-auth
session    required     pam_stack.so service=system-auth
lark/root [/etc/pam.d] # cat system-auth
#%PAM-1.0
auth       requisite    /lib/security/pam_nologin.so
auth       requisite    /lib/security/pam_env.so
auth       sufficient   /lib/security/pam_afs.krb.so ignore_uid 0
auth       sufficient   /lib/security/pam_pwdb.so
auth       requisite    /lib/security/pam_deny.so
account    required     /lib/security/pam_pwdb.so
password   required     /lib/security/pam_cracklib.so retry=3 type= minlen=8 difok=5
password   sufficient   /lib/security/pam_pwdb.so use_authtok shadow md5
password   requisite    /lib/security/pam_deny.so
session    required     /lib/security/pam_limits.so
session    required     /lib/security/pam_pwdb.so
session    optional     /lib/security/pam_afs.krb.so remainlifetime 180
session    optional     /lib/security/pam_console.so

/var/log/secure:

May 20 09:42:43 swan xinetd[1603]: START: exec pid=14803 from=152.2.129.13
May 20 09:42:43 swan xinetd[14803]: USERID: exec OTHER
:[U2FsdGVkX1+HGnIXs2KUONcPPv66iL8P2cCX8yMAtlQ=]
/var/log/messages:

I updated the sytem, (accept the kernel), to rhel update 5, here is the
rpm info:

sopko@lark:8% rpm -q pam glibc
pam-0.75-64
glibc-2.3.2-95.33
sopko@lark:20% sopko@lark:8% rpm -q pam glibc
sopko@lark:8%: Command not found.
sopko@lark:21% pam-0.75-64
pam-0.75-64: Command not found.
sopko@lark:22% glibc-2.3.2-95.33

Comment 7 Karel Zak 2005-05-20 14:12:41 UTC
There is one important change in the latest rexecd: it uses pam session. The old
version didn't open/close pam session. We added pam session support to rexecd,
because it's better for security (old version for example ignore
/etc/security/limits, see bug #68590).

You close the bug, does't mean you resolve it?

Comment 8 Karel Zak 2005-05-20 14:13:42 UTC
s/does't/does/ :-)

Comment 9 Tomas Mraz 2005-05-20 14:25:08 UTC
Yes, this is a configuration error. The 'session ... pam_console.so' should not
be in the /etc/pam.d/system-auth. This module in session phase should be used
only for login and gdm/xdm/kde services.



Comment 10 John Sopko 2005-05-20 15:27:50 UTC
If I comment out my pam_afs module this fixes, rexec now works with
pam.d/system-auth set to this:

auth       requisite    /lib/security/pam_nologin.so
auth       requisite    /lib/security/pam_env.so
auth       sufficient   /lib/security/pam_afs.krb.so ignore_uid 0
auth       sufficient   /lib/security/pam_pwdb.so
auth       requisite    /lib/security/pam_deny.so
account    required     /lib/security/pam_pwdb.so
password   required     /lib/security/pam_cracklib.so retry=3 type= minlen=8 difok=5
password   sufficient   /lib/security/pam_pwdb.so use_authtok shadow md5
password   requisite    /lib/security/pam_deny.so
session    required     /lib/security/pam_limits.so
session    required     /lib/security/pam_pwdb.so
#session    optional    /lib/security/pam_afs.krb.so remainlifetime 180
session    optional     /lib/security/pam_console.so


Note You need to log in before you can comment on or make changes to this bug.