Hi,
First of all, please note that I currently have xterm Version: 235-2
installed.
With xterm Version: 261-1 installed, when I run this command,
$ exec login USER
the xterm immediately exits. This problem does not occur with prior
versions of xterm installed, eg, Version: 235-2.
Note that on my system, login is setuid root, thus enabling exec-ing
login from the base level shell, on e.g., tty1, pts/2, to work.
$ ls -l /bin/login
-rwsr-xr-x 1 root root 36896 Sep 25 18:05 /bin/login
Here is a typescript of the correct xterm behavior using Version: 235-2.
$ id
uid=1001(jeff) gid=1001(jeff) groups=1001(jeff),4(adm),20(dialout),24(cdrom),25(floppy),29(audio),30(dip),201(xlocal)
$ exec login jss
Password:
Last login: Sat Jan 22 16:57:50 EST 2011 on pts/6
Linux l2 2.6.32-5-amd64 #1 SMP Wed Jan 12 05:14:59 UTC 2011 x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
You have mail.
$ id
uid=1002(jss) gid=1002(jss) groups=1002(jss),4(adm),29(audio),201(xlocal)
$ who
jeff tty1 Jan 29 16:11
jeff pts/1 Jan 29 16:13 (:0.0)
jeff pts/0 Jan 29 16:13 (:0.0)
jsroot pts/2 Jan 29 16:13 (:0.0)
jss pts/3 Jan 29 16:28 (:0.0)
jsroot pts/4 Jan 29 16:13 (:0.0)
jeff pts/5 Jan 29 16:16 (:0.0)
Thanks,
Jeffrey Sheinberg
Hi Jeffrey. Jeffrey Sheinberg <jeff@bsrd.net> (29/01/2011): | $ login USER | No utmp entry. You must exec "login" from the lowest level "sh" Now, if you use “exec”, you're replacing xterm by the login binary, which returns (due to wrong usage), meaning your (previously-xterm) process returns, which isn't exactly a bug in xterm. The same happens with e.g. xfce4-terminal, so I guess xterm isn't at fault here. Please note that I tried with the same permission as yours on login: | $ ls -l /bin/login | -rwsr-xr-x 1 root root 45384 Sep 26 15:59 /bin/login Looks like notabug to me, but I'll wait a bit before closing it. KiBi.
(lowest level) shell with /bin/login. In my original submission, I provided a typescript where xterm Version: 235-2 handles the exec of login without any problems. Do you see how user 'jeff' becomes user 'jss' in that typescript? see my above comments. I would guess that this bug was introduced into xterm Version: 261-1 with the new "utempter" library. Thanks,
I can reproduce this difference without the utempter library (though it's possible that the problem is related to ifdef's for it). I'll look for a solution and close out #268 "soon" (have been busy setting up new development machines).
hmm - my quick check "without" was also without setgid, so there was no utmp entry. Reading the source for login, I see that the error message comes from a check (a) not running as root and (b) no valid utmp entry found. Given that, the likely explanation is that login is dropping the setuid itself. I don't see that in the unpatched source, but see comments in the Debian patch which indicate that's intended behavior. Looks like a possible workaround would be to use sudo or other wrapper that holds the setuid behavior.
Hi Thomas,
1. As I originally wrote, I can "exec login" from xterm-235-2
successfully, but not from xterm-261-1, with no other changes to
my system.
2. Cyril noted in his reply that xfce4-terminal behaves similar to
xterm-261-1, so I checked this out, I also tried it for lxterminal - but
they have a different behavior than xterm-261-1,
A. Xterm-261-1 seems to exit without ever invoking the login
authentication process.
B. Both xfce4-terminal and lxterminal invoke login and the
authentication process is successful (it's in the syslog), and then
they each exit.
So I still maintain that there is a bug in xterm-261-1 compared to
xterm-235-2.
Thanks,
right - essentially that's because #235 is setgid to utmp, and opens the utmp file directly. With utempter, there's a separate process that opens it. thanks - I'll look/see why they're different from xterm. ldd tells me they're not using utempter, for instance. no problem (will keep studying it)
looking at lxterminal now, and compiling the login program to add some traces, I'm seeing _that_ fail at the same point, with the same cause. (I'll compare with xfce4-terminal this evening, and investigate whether one of the Debian packages might change this behavior).
I did look further, found that in my configuration at least, that I was unable to get a login prompt from the unmodified setuid-login program for either lxterminal or xfce4-terminal (or even gnome-terminal). I simply copied /bin/login to /usr/local/bin/root-login, making it setuid and setgid to root:staff Since that prompt is what I understood "authentication process" to refer to above, I'm puzzled - need more info to reproduce the case where I would be seeing the VTE-based terminals working as you describe.
Hi Thomas,
Here are some details on my setup,
# dpkg-query -l login xterm lxterminal xfce4-terminal
ii login 1:4.1.4.2+svn3 system login tools
hi xterm 235-2 X terminal emulator
ii lxterminal 0.1.8-2 desktop independent vte-based terminal emula
ii xfce4-terminal 0.4.5-1 Xfce terminal emulator
# type login
login is /bin/login
# ls -l /bin/login
-rwsr-xr-x 1 root root 36896 Sep 25 18:05 /bin/login
; Notice that login is setuid to root, and is not setgid.
;-----------------------------------------------------------------------
; Now I login from user jeff on pts/2 to user jsroot on same pts/2.
$ exec login jsroot
Password:
Last login: Fri Feb 11 08:42:34 EST 2011 on pts/3
...
# grep 'Feb 13 14:52:34 l2 login' /var/log/syslog
Feb 13 14:52:34 l2 login[6460]: pam_sm_authenticate: Called
Feb 13 14:52:34 l2 login[6460]: pam_sm_authenticate: username = [jsroot]
Feb 13 14:52:34 l2 login[6460]: pam_unix(login:session): session opened for user jsroot by jeff(uid=1001)
Feb 13 14:52:34 l2 login[6605]: ROOT LOGIN on '/dev/pts/2' from ':0.0'
; So the above is successful using xterm 235-2. Note that the above xterm has
; a PPID of 1 (init), since it was run from my $xclient, while the following
; VTEs have a PPID of 6461, which is the PID of the bash process that launched
; the VTE from pts/3.
;-----------------------------------------------------------------------
; Now startup xfce4-terminal (run from pts/3).
$ xfce4-terminal &
[1] 9545
; At this point an xfce4-terminal pops up, let $$ be its prompt.
$$ exec login jsroot
; The xfce4-terminal now disappears, and there was no Password: prompt,
; and there was nothing in /var/log/syslog from login at this time.
$
[1]+ Done xfce4-terminal
; Now I startup lxterminal just like xfce4-terminal, and I get the same
; results as for xfce4-terminal - immediate exit on 'exec login jsroot',
; no Password: prompt, and nothing from login in the syslog.
;-----------------------------------------------------------------------
; Now I just before install xterm 261-1, I try the same xfce4-terminal and
; lxterminal scenarios using instead xterm 235-2.
$ xterm &
[1] 10080
; At this point an xterm pops up, let $$ be its prompt
$$ exec login jsroot
Password:
Last login: Sun Feb 13 17:20:51 EST 2011 on pts/6
; Back at the xterm on pts/3 where I just ran 'xterm &'.
$
; Now I exit from the xterm where I successfully logged in as jsroot
$$
; Back again at the xterm on pts/3 where I just ran 'xterm &'
$ Cannot chmod /dev/pts/6 to 666 currently 620: Operation not permitted
; Why does the above error message get output to pts/3?
;
; Here are the syslog entries for this last login to jsroot,
Feb 13 17:26:17 l2 login[10081]: pam_sm_authenticate: Called
Feb 13 17:26:17 l2 login[10081]: pam_sm_authenticate: username = [jsroot]
Feb 13 17:26:17 l2 login[10081]: pam_unix(login:session): session opened for user jsroot by jeff(uid=1001)
Feb 13 17:26:17 l2 login[10153]: ROOT LOGIN on '/dev/pts/6' from ':0.0'
Feb 13 17:29:22 l2 login[10081]: pam_unix(login:session): session closed for user jsroot
;-----------------------------------------------------------------------
; Now I install xterm 261-1.
# apt-get install xterm=261-1
...
Setting up xterm (261-1) ...
...
; Switch to pts/3, where I'll launch an xterm (261-1) in the background.
$ dpkg-query -l xterm
hi xterm 261-1 X terminal emulator
$ who
jeff tty1 Feb 13 14:37
jeff pts/0 Feb 13 14:52 (:0.0)
jeff pts/1 Feb 13 14:52 (:0.0)
jsroot pts/2 Feb 13 14:52 (:0.0)
jeff pts/3 Feb 13 14:52 (:0.0)
jsroot pts/4 Feb 13 14:52 (:0.0)
jeff pts/5 Feb 13 14:59 (:0.0)
$ xterm &
[1] 11422
; At this point an xterm pops up, let $$ be its prompt
; Switch to pts/6, where [1] 11422 is running in the background.
$$ tty
/dev/pts/6
$$ logname
jsroot
; Why is logname jsroot on pts/6? May have something to do with having
; successfully done 'exec login jsroot' from xterm 235-2 on pts/6 in the
; first example above.
$$ who
jeff tty1 Feb 13 14:37
jeff pts/0 Feb 13 14:52 (:0.0)
jeff pts/1 Feb 13 14:52 (:0.0)
jsroot pts/2 Feb 13 14:52 (:0.0)
jeff pts/3 Feb 13 14:52 (:0.0)
jsroot pts/4 Feb 13 14:52 (:0.0)
jeff pts/5 Feb 13 14:59 (:0.0)
jeff pts/6 Feb 13 19:05 (:0.0)
$$ exec login jsroot
; Xterm process on pts/6 exits, no login prompt, no entry in syslog,
; just like with xfce4-terminal and lxterminal.
; Back to pts/3.
$
[1]+ Done xterm
$ who
jeff tty1 Feb 13 14:37
jeff pts/0 Feb 13 14:52 (:0.0)
jeff pts/1 Feb 13 14:52 (:0.0)
jsroot pts/2 Feb 13 14:52 (:0.0)
jeff pts/3 Feb 13 14:52 (:0.0)
jsroot pts/4 Feb 13 14:52 (:0.0)
jeff pts/5 Feb 13 14:59 (:0.0)
;-----------------------------------------------------------------------
If you can think of any other scenarios that you would like me to try,
I will be happy to do so.
Thanks,
aside from the xterm, I have the same versions here (of course I can modify xterm). ok - shouldn't make much difference (I think). ok (I'd be generally running all of those from the command-line, to simplify comparison). on the machine I'm comparing at the moment, the pam messages are going to auth.log syslog is only getting unrelated messages (including a bunch of segfaults from the kernel - that's 2.6.32-5-686, from an install of Debian/testing about a month ago). That's consistent with what I was seeing. But your comment in message #30 seemed to be saying that you got a prompt then. I see the comment about about the authentication messages from pam in the log - will check on that. The error message is written to xterm's stderr, which would be in the shell from where it was launched. The 666 would be when xterm's trying to cleanup the pty permissions, and may be failing since the ownership changed unexpectedly (from xterm's viewpoint, since it doesn't know about login being setuid to root). I'd assume it's looking at the pty and seeing the utmp record that was updated. But the "who" below should be using the same info (not sure yet). I'll see what I can digest from this - thanks
Hi Thomas,
I tried your above suggestion, in my case I used su like this,
$ su -l jsroot
to get a user "jsroot" login shell.
I have decided it is not appropriate to expect "exec login jsroot" to work,
even though it seemed to work when /bin/login is setuid 0 and xterm 235-2 was
installed. I say seemed to work because, actually, the count of logged in
users on my system was always off by +1 when I used this technique.
Now, when I get a "jsroot" login shell via "su -l jsroot", the following
situation exists,
# tty
/dev/pts/2
# logname
jeff
# var user logname
export USER='jsroot'
export LOGNAME='jsroot'
# who | grep pts/2
jeff pts/2 Mar 26 09:18 (:0.0)
And when I then launch an xterm from this "jsroot" login shell on pts/2,
I have problems with xterm 261-1 & 276-2, like this,
# tty
/dev/pts/6
# logname
root
# var user logname
export USER='jsroot'
export LOGNAME='root'
# who | grep pts/6
root pts/6 Mar 26 16:12 (:0.0)
while xterm 235-2 works correctly, like this,
# tty
/dev/pts/6
# logname
jsroot
# var user logname
export USER='jsroot'
export LOGNAME='jsroot'
# who | grep pts/6
jsroot pts/6 Mar 26 16:02 (:0.0)
Note that both lxterminal 0.1.8-2 and xfce4-terminal 0.4.5-1 exibit the same
(IMO, correct) behavior as xterm 235-2 in this case.
I believe that the behavior exhibited by xterm 235-2, lxterminal 0.1.8-2, and
xfce4-terminal 0.4.5-1, in the above typescripts, is in accordance with the use
of "su -l USER", while the behavior of xterm 261-1 and xterm 276-2 is not in
accordance with "su -l USER", because I have previously su-ed to a login
sub-shell as user "jsroot", not as user "root".
Here is what POSIX $xcu/getlogin.html says,
...
The login name shall be the string that would be returned by the getlogin()
function defined in the System Interfaces volume of POSIX.1-2008.
and POSIX $xsh/getlogin.html says,
...
Three names associated with the current process can be determined: getpwuid
( geteuid()) shall return the name associated with the effective user ID of
the process; getlogin() shall return the name associated with the current
login activity; and getpwuid( getuid()) shall return the name associated
with the real user ID of the process.
...
The getlogin() function returns a pointer to the user's login name. The
same user ID may be shared by several login names. If it is desired to get
the user database entry that is used during login, the result of getlogin()
should be used to provide the argument to the getpwnam() function. (This
might be used to determine the user's login shell, particularly where a
single user has multiple login shells with distinct login names, but the
same user ID.)
In other words, xterm 261-1 and xterm 276-2 should set the utmp entry for the
newly launched xterm so that getlogin() works properly. As long as the uid of
the user database entry for the USER environmental variable is the same as the
value returned by getuid(), then USER should be set in the utmp entry for the
xterm. Otherwise, the same logic would apply for the LOGNAME variable. Only
when both of these alternatives fail, then xterm should fallback to setting the
utmp entry to getpwuid( getuid()).
Thanks,
sounds good (I wasn't getting far with this, last year, though I'd not
given up).
hmm - I'll have to investigate this. It sounds as if you're referring
to the effect of this chunk in main.c:
login_name = NULL;
if (x_getpwuid(screen->uid, &pw)) {
login_name = x_getlogin(screen->uid, &pw);
}
which (is supposed to follow this guideline):
/*
* If the logon-name differs from the value we get by looking in the
* password file, check if it does correspond to the same uid. If so,
* allow that as an alias for the uid.
*/
...so perhaps there's some information that I've discarded before that
point.
sounds good (I wasn't getting far with this, last year, though I'd not
given up).
hmm - I'll have to investigate this. It sounds as if you're referring
to the effect of this chunk in main.c:
login_name = NULL;
if (x_getpwuid(screen->uid, &pw)) {
login_name = x_getlogin(screen->uid, &pw);
}
which (is supposed to follow this guideline):
/*
* If the logon-name differs from the value we get by looking in the
* password file, check if it does correspond to the same uid. If so,
* allow that as an alias for the uid.
*/
...so perhaps there's some information that I've discarded before that
point.
I can make $USER and $LOGNAME the same in the xterm as in its parent, but utempter doesn't provide a way to set the user's name which would show up in "who". It only has parameters for hostname and pty name. It fills in the user and date by itself.
I can make $USER and $LOGNAME the same in the xterm as in its parent, but utempter doesn't provide a way to set the user's name which would show up in "who". It only has parameters for hostname and pty name. It fills in the user and date by itself.
I can make $USER and $LOGNAME the same in the xterm as in its parent, but utempter doesn't provide a way to set the user's name which would show up in "who". It only has parameters for hostname and pty name. It fills in the user and date by itself.
xterm patch #279 implements the improvement I suggested. To actually fix the problem reported will take further changes, to libutempter itself. (I might do that, though iirc libutempter lacks a maintainer...).
xterm patch #279 implements the improvement I suggested. To actually fix the problem reported will take further changes, to libutempter itself. (I might do that, though iirc libutempter lacks a maintainer...).
Control: reassign -1 libutempter0
Control: affects -1 xterm screen tmux
The reason is that starting with version 247-1 xterm is no longer setgid
but uses libutemper to update /var/run/utmp. The same behavior can be
seen in screen and tmux which also terminate immediately upon
"exec login USER".
Cheers,
Sven
Am Sa., 5. Okt. 2019 um 07:59 Uhr schrieb Sven Joachim <svenjoac@gmx.de>: I do not quite understand the problem. Yes, xterm exits when running 'exec login USER' as non-root. That is because 'login USER' fails as non-root and 'exec' exits on failure. Test 'exec /bin/false'.
Control: affects -1 =
Control: reassign -1 xterm 261-1
Control: tags -1 moreinfo
Err, of course, sorry for the noise. I should have had more coffee this
morning and read the bug report more carefully. The bug submitter had a
suid /bin/login, but even after "chmod 4755 /bin/login" I cannot use
that to actually login:
,----
| $ LANG=C exec login sven
| No utmp entry. You must exec "login" from the lowest level "sh"
`----
And this happens even at the Linux console, so libutempter is out of the
question. Running login as root with 'exec su -c "login sven"' succeeds,
though (with a double password prompt from su and login).
Reassigning back to xterm for now, but I don't see xterm doing anything
wrong. And it is definitely not going back to setgid utmp.
Cheers,
Sven
אני יוצר איתך קשר בנוגע לבני משפחתך שנפטרה בירושה ללא תביעות בשווי 5.5 מיליון דולר ארה"ב. השב להודעת דוא"ל זו בהקדם כדי להמשיך בפרטים. שלך תמיד,כריסטיאן מרטינז, (עורך דין)
fwiw, the same issue applies to gnome-terminal, konsole (which by the way triggers a null pointer exception), and urxvt. Since it's not going to be fixed (and hasn't been demonstrated to be a bug _in_ xterm), I'd rather just close this one.
fwiw, the same issue applies to gnome-terminal, konsole (which by the way triggers a null pointer exception), and urxvt. Since it's not going to be fixed (and hasn't been demonstrated to be a bug _in_ xterm), I'd rather just close this one.
see discussion: not a bug in xterm