su command breaks utmp log in Alt Linux Master 2.2 + updates and w/who commands show wrong info Example: [ivan@eagle ivan]$ ssh sirius ivan@sirius's password: Last login: Mon Feb 2 13:25:52 2004 from eagle.n-ix.com.ua [ivan@sirius ivan]$ w 13:26:40 up 17:23, 1 user, load average: 0.00, 0.00, 0.00 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT ivan pts/0 eagle.n-ix.com.u 1:26pm 0.00s 0.07s 0.01s w [ivan@sirius ivan]$ su - Password: [root@sirius root]# w 13:26:45 up 17:23, 2 users, load average: 0.00, 0.00, 0.00 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT ivan pts/0 eagle.n-ix.com.u 1:26pm 0.00s 0.15s 0.10s /usr/sbin/sshd root pts/0 localhost 1:26pm 0.00s 0.15s 0.02s w [root@sirius root]# Now, open another one connection to this server: [ivan@eagle ivan]$ ssh sirius ivan@sirius's password: Last login: Mon Feb 2 13:26:39 2004 from eagle.n-ix.com.ua [ivan@sirius ivan]$ w 13:27:39 up 17:24, 3 users, load average: 0.00, 0.00, 0.00 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT ivan pts/0 eagle.n-ix.com.u 1:26pm 54.00s 0.13s 0.10s /usr/sbin/sshd ivan pts/1 eagle.n-ix.com.u 1:27pm 0.00s 0.05s 0.01s w root pts/0 localhost 1:26pm 54.00s 0.13s 0.06s -bash [ivan@sirius ivan]$ su - Password: [root@sirius root]# w 13:27:44 up 17:24, 3 users, load average: 0.00, 0.00, 0.00 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT ivan pts/0 eagle.n-ix.com.u 1:26pm 59.00s 0.13s 0.10s /usr/sbin/sshd ivan pts/1 eagle.n-ix.com.u 1:27pm 0.00s 0.09s 0.08s /usr/sbin/sshd root pts/1 localhost 1:27pm 0.00s 0.09s 0.01s w [root@sirius root]# Now you can notice absence of the line root pts/0 localhost 1:26pm 54.00s 0.13s 0.06s -bash Steps to Reproduce: 1. ssh to ALM2.2 as user 2. issue "su" command 3. open another ssh connection to the ALM2.2 server 4. issue "su" command Actual Results: you will see three entries Expected Results: there should be four entries
Does logout from second root session (pts/1) unhides first root session (pts/0)?
yes, if I logout second root session, first one apears again: [root@sirius root]# w 00:34:35 up 2 days, 4:31, 3 users, load average: 0.00, 0.00, 0.00 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT ivan pts/0 post-gw.litech.n 12:30am 4:23 0.10s 0.10s /usr/sbin/sshd ivan pts/1 post-gw.litech.n 12:30am 0.00s 0.17s 0.10s /usr/sbin/sshd root pts/1 localhost 12:34am 0.00s 0.17s 0.02s w [root@sirius root]# logout [ivan@sirius ivan]$ w 00:34:51 up 2 days, 4:31, 3 users, load average: 0.00, 0.00, 0.00 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT ivan pts/0 post-gw.litech.n 12:30am 4:39 0.10s 0.10s /usr/sbin/sshd ivan pts/1 post-gw.litech.n 12:30am 0.00s 0.09s 0.01s w root pts/0 localhost 12:30am 4:39 0.10s 0.04s -bash [ivan@sirius ivan]$
I can reproduce this in Sisyphus, thanks.
Created attachment 341 [details] SimplePAMApps-0.60-owl-login-su-ut_id-undo.patch This patch (partial undo of the SimplePAMApps-0.60-owl-login-su-ut_id.patch) fixes the problem. Looks like ut_id calculation algorithm in our SimplePAMApps differs from openssh and libutempter. I'll contact origin of the patch about that.
It looks it's not a good patch. I've applied it to the SimplePAMApps-0.60-alt15.src.rpm, build it and installed. After that if I issue "su -" command, my name changes to "root" in "w" command, while in *nix systems I've ever used, after su'ing, "w" command shows my real login. Note: when using "su" command without "-" parameter the username has not been changed. Furthermore, after issuing "su -" command breaks lastlog and shows a lot of fake 00:00 records. I've changed a serverity of this bug, because it make really difficult to use ALM2.2 in multiuser environment, when on servers are present a lot of people.
When you login with "su -l", your login name changes. When you run "su" without "-l", your login name remains unchanged. Also, I see no fake records in output of the "last" command: joe pts/1 :0 Fri Feb 6 23:51 still logged in root pts/1 localhost Fri Feb 6 23:51 - 23:51 (00:00) joe pts/1 :0 Fri Feb 6 23:50 - 23:51 (00:00) When user joe issued "su -", user root logged on pts/1. That is, joe is not logged in on pts/1 untill root is logged out from pts/1. What's wrong with that? btw, I don't care of *unix systems which mishandle the "su -" case.
Responce from origin of the patch: "Actually, the desired behavior is not what Ivan describes. Namely, the intent of that code in su is to temporarily replace the entry, not to add a new one. So the desired result would be to have two entries (for two root sessions), not four."
Ok, I'm really sorry if I had hurt your feelings somehow, but I don't understand why you are so sure, that other *nix-es mishandles "su -". Here is a comment from su.c of rh9: -, -l, --login Make the subshell a login shell. Unset all environment variables except TERM, HOME and SHELL (set as above), and USER and LOGNAME (set unconditionally as above), and set PATH to a default value. Change to USER's home directory. Prepend "-" to the shell's name. If it'll be interesting for you same behavor have had all SCO unixes, saving correction hp-ux, and a lot of other linux distributions. Next, I agree that there should be two entries, not four. Ok, that's fine. Again, if it'll be interesting for you I explain, why I think that current behaivor, when su replaces entry with "root" username is not correct. With such behaivor I can't see which users are currently in system. I see only "root","root","root" ... Moreover, I can't see from where they have loggen in, because "su -" changes FROM field to localhost now. It's really not good from the administration point of view. And way of thinking that the user, who have used "su -" command has logged out is a nonsense! After logout from su shell it don't logout the system, it's going back to the user shell. Furthermore, if you issue "su -" command user process "bash" has an owner of "user". And system reports, that user is not in the system! Further, according to lastlog after logout from su shell user logins to the system, but any logs doesn't have any information about users login. It makes me think, that my system were cracked. I would like to discuss this problem, and no way to hurt your filling, so please don't be so brute in your answers, like in your sentence "btw, I don't care of *unix systems which mishandle the "su -" case. " May be there is a reason, why other "*unix systems which mishandle the "su -" case. " ?
Still maybe there isn't: there were several su implementations floating around for a long time, and the semantics differed quite noticeably.
Ok. Of course it's ALT prerogative to deside how "su" should work in your distribution. I want to let you know, that is unaccustomed after rh,suse,and unixes because of described reasons. And I'm still sure that it's not usefull to replace utmp record with info "root bla-bla localhost". Nothing informative. Now, to get information about who is in the system I have to use something like ps -ef | grep -- -bash | grep -v grep, and to get info about source of connection I should make a deep magic with lastlog or netstat. And last one, I want to ask you when approx. will be available update at least with provided patch?
One more question to clarify the situation: I think that after "su -" logname(1) should print "root". Do you agree with this assumption? About timelines, I'm not decided yet how to fix the issue since it may change behaviour.
Thanks for your quick answer, Dmitry. Now, about your question touching logname(1). I've made a little investigation. I tried following command sequence in rh6.2/7.3/9, sco osr5/unixware7 : 1. login as regular user "ivan" 2. su - 3. logname in all cases (5 times) I got from logname output "ivan". It looks like all of them don't make changes in utmp log after issuing "su -" command. I don't have access on weekend to suse/solaris, but I think there will be same situation. ok, now back to our subject at hand. I think it's good for logname to return "root" in "su -" environment, but it's bad to remove (change utmp entry for) user, who did not logged out. He's in the system, he has issued "su -" command, but he didn't logged out. That's my oppinion. May be it really makes a sense not to change utmp entry but add another for "su -" session? How do you think?
Concerning your OS review, I'd like to know *BSD behaviour in this case. Adding second utmp entry with the same ut_line will result to uncertainty in getlogin(3) behaviour, and therefore in logname(1) output: it will return first record with given ut_line.
Ok, *bsd behavior I'll describe tomorrow, since I have no access to that OS during weekend also.
Created attachment 342 [details] SimplePAMApps-0.60-owl-alt-login-su-ut_id.patch Here is a patch I'm going to use instead of SimplePAMApps-0.60-owl-login-su-ut_id.patch
Could you please describe in few words behaviour of su after applying this patch and after which patch I have to apply it when building? Now about *bsd behaviour of "su -": FreeBSD 4.9-RELEASE-p1 : ssh hellfire -l admin Password: hellfire-admin:~ >$ su - Password: hellfire-root:~ ># logname admin hellfire-root:~ ># --------------- FreeBSD 4.8-RELEASE: ssh thewall Password: kazantip:~ >$ su - Password: root:~ ># logname kazantip I've also checked in suse9 -- same situation, after "su -" logname(1) returns regular user name, not "root". So, how will ALT handle this situation?
Fixed in 0.60-alt20 (Sisyphus) and 0.60-owl22 (Owl-current): SimplePAMApps-0.60-owl-alt-login-su-ut_id.patch replaces SimplePAMApps-0.60-owl-login-su-ut_id.patch Thanks for interesting discussion.
thanks for fixing.
Will be fixed rpm available as update for ALM2.2?
Do you think it worths errata?
I think worth. If it's interesting for you, I'm running ALM2.2 as db/router/access servers. I'm planning 28 alm2.2 server installations in region (now I've five), and people are working in terminal mode there. It means that all of them do ssh to the servers. Some servers have 50 concurent on-line users load. And it's vitaly to know how much people there are on-line. The same reason was why I wanted ALM behaviour to be the same as other linuxes/unixes in logname(1) handling. But as I understood you decide to left it as it was. And AFAIK ALM2.2 is last available stable server distribution from ALT (am I wrong? compact is beta, isn't it?), so I think fixes of such problems in core utils should be available via apt-get.
Ok, I'llprepare update for ALM2.2
thank you
