Hide Forgot
Description of problem: I'm getting intermittent failure when trying to login in to an FC3 box using rlogin. All the client side gets is a "connection closed" message. There are no errors logged on the server side. Version-Release number of selected component (if applicable): rsh-server-0.17-23 How reproducible: Easy but not 100%. Steps to Reproduce: 1. Install rsh-server. 2. Enable rlogin in /etc/xinetd.d/rlogin and restart xinetd. 3. In a user account on the server set up a ~/.rhosts file for password-free login from some other host. 4. From that other host repeatedly try to rlogin to the server. Actual results: Sometimes it will work. Sometimes it will fail with a "connection closed" message. Sometimes it will work but take unusually long time (several seconds) to complete the connection. Expected results: Successful connection every time. Additional info: I don't know if it's related or not, but after a successful login this error is written to /var/log/secure on the server side upon logging back out: Nov 28 18:50:36 chinook login: Warning! Could not relabel /dev/pts/2 with user_u:object_r:devpts_t, not relabeling.
1/ Dont't forget if you call "rsh" without command it uses "rlogin". It means in this case you need to enabled "rlogin" in the /etc/xinetd.d/rlogin too. For testing is good use something like: "/usr/bin/rsh <host> ls". 2/ You need to add "rsh", "rlogin" to /etc/securetty too. 3/ Must be possible connect from server to client. The rsh/rlogin uses reverse (stderr) connection. So there is two(!) connections, client->server and server->client. Maybe you can try disable iptables (service iptables stop) for your tests. 4/ Your server must be enable convert client IP to full client hostname. 5/ in the file ~/.rhosts is required full client hostname. If you have still a problem connect to your server, please add to your bugreport "strace" outputs: Client: $ strace -f -o client.trace /usr/bin/rsh <host> Server (it's more dificult): - create shell script: #!/bin/bash /usr/bin/strace -f -o /tmp/server.trace /usr/sbin/in.rshd - add path to this script to /etc/xinetd.d/rsh (options server=) - restart xinetd (service xinietd restart) - check the file /tmp/server.trace on server after failed connection
Note: with strace on client you can have a permission problem as non-root user.
None of ideas #1 through #5 would explain the intermittent nature of the problem. When I say intermittent I really mean it. One second it will work. A few seconds later it will fail. A few seconds later it might work again. That's not a problem with my system configuration. I'm attaching two client-side strace output files. One shows a successful rlogin and the other a failure. In the successful case you can see where it makes the connection, reads "exit\n" as I type it in at the remote shell prompt, and the session is closed normally. In the failure case you can see that the connection is initially successful but at the point where the remote shell (bash) tries to read a command from stdin it gets an ERESTARTSYS error code and the session is terminated. This is wrong. It's as though the ERESTARTSYS error code is being treated as a real error instead of a request to restart the system call.
Created attachment 107819 [details] Client-side strace of a successful rlogin
Created attachment 107820 [details] Client-side strace of a failed rlogin.
Thanks for your strace outputs. You didn't use "-f", so in your strace output missing client child process that read data from server (client uses two processes). Please, can you do it again and for server too. And --please-- use "-f" option for strace :-) I don't see problem in your actual strace output, but we don't know why client child process was exited. ERESTARTSYS is only ptrace information about kernel internal stuff and it doesn't return to userspace. It's no problem. Please, check your server PAM setting. The "rlogin" use it and for example pam_limits setting can disable login to server if there is used all user's resources.
I am also having this problem. It did not appear to happen until after I updated all of the packages on the system. Booting into the stock kernel seems to solve the problem for now. I have used the same configuration successfully on a RH9 system.
Thought I'd add that the error only happens once in a while, and I can't seem to tie it down to any particular happening. I executed the same command twice within seconds of each other and one failed and one was successful. I happened to be strace'ing the execution (as shown above with the -f) and will be attaching them.
Created attachment 108391 [details] sucessful client side trace
Created attachment 108392 [details] un-sucessful client side trace
Make, can you try server side (rlogind) strace too. I think client side looks without problems. By the way, "rsh" without command, calls "rlogin".
I'm currently strace'ing the rlogin as shown above and now the problem doesn't occur. Is there a possiblity of a timing issue that strace is taking care of. The reason that I mention this is that rlogin seems a little bit slower than when it isn't running through strace on the server. I've tried around 600 rlogins and haven't had a problem. Seems kinda wierd to me.
It looks like bug #137808 -- this bug isn't possible detect with strace or gdb :-( The problem is somewhere around place where the "login" tries initialize pseudo terminal.
Too bad some of us aren't authorized to see #137808.
So, has anyone found a solution for this? I also am interested, and am also unable to view #137808
Can anyone confirm this bug on actual FC4?
Closing due to lack of response. FC3 is the responsibility of Fedora Legacy now, and this is not a security issue. (Indeed, using rlogin rather than ssh is more of a security issue.) If this occurs in FC4 or FC5, please reopen.