similar to: [Bug 214] New: IRIX utmp problem loginrec.c: line_abbrevname() goes wrong

Displaying 20 results from an estimated 100 matches similar to: "[Bug 214] New: IRIX utmp problem loginrec.c: line_abbrevname() goes wrong"

2002 Apr 23
1
[Bug 214] IRIX utmp problem loginrec.c: line_abbrevname() goes wrong
http://bugzilla.mindrot.org/show_bug.cgi?id=214 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From djm at mindrot.org 2002-04-23 23:08 ------- Similar patch applied - please test tommorow's
2001 Sep 06
0
line_abbrevname patch
Once upon a time there were two places in the loginrec code that were ifdef'd sgi and which stripped the "tty" off the line along with the "dev" when recording utmp. (Specifically it was being done in line_stripname and line_abbrevname.) Doing that in line_stripname was wrong, because it broke things like wall that expected the ut_line to have the "tty" present.
2019 Jul 14
0
[ANNOUNCE] xbiff 1.0.4
xbiff provides graphical notification of new e-mail. It only handles mail stored in a filesystem accessible file, not via IMAP, POP or other remote access protocols. Alan Coopersmith (7): configure: Drop AM_MAINTAINER_MODE autogen.sh: Honor NOCONFIGURE=1 Update README for gitlab migration Update configure.ac bug URL for gitlab migration Use _CONST_X_STRING to make
2024 Jan 20
0
[ANNOUNCE] xbiff 1.0.5
xbiff provides graphical notification of new e-mail. It only handles mail stored in a filesystem accessible file, not via IMAP, POP or other remote access protocols. This release adds -help & -version command line options. For those building for 32-bit platforms, it also enables use of the "large file" APIs so that it can handle mailboxes which exceed 2gb or which may be stored on
2000 Dec 01
3
two irix patches
First, does anyone know why the following was added in the first place? It purposely strips the tty off of tty names (e.g., ttyq1 becomes q1) before sticking them in wtmp. IRIX then has no idea what terminal people are attached to, causing commands like wall to fail (as they try to open /dev/q1). Maybe this should be version specific? --- openssh-SNAP-20001129.orig/loginrec.c Thu Nov 9
2005 Jun 29
1
inconsistent ut_id values in the utmp(x) file
Hi, In loginrec.c, the 'line' string utility function line_abbrevname() returns the last four characters of the terminal file path. This returned value is assigned to the utmp structure member ut_id[4]. Some sample ut_id values are shown below: /dev/pts/1 will have ut_id set to ts/1 /dev/pts/2 will have ut_id set to ts/2 . . /dev/pts/9 will have ut_id set to ts/9 /dev/pts/10
2005 Oct 11
2
Numpty question about EXISTS...
I'm fiddling with Ruby and its IMAP class. I'm trying to write something which (at this stage) can be thought of as a variant on xbiff which doesn't need poll the server to establish the presence of new mail... I'd like to establish a notification when the contents of a folder changes... which is likely to be when a different IMAP client moves a message into a new folder.
2004 Jul 18
0
HPUX and privsep
Subject: HPUX and privsep Anyone solved or see the same connection I do with these two issues on HPUX if Privilege Separation is turned off ? Logname not found (3.7.1p2, 3.8.1p1) Login prematurely quits during session setup (mm_send_fd: sendmsg(3): Bad file number | mm_receive_fd: recvmsg: expected received 1 got 0) (3.8.1p1) Seems the mm_xxxx_() functions arent called when PrivSep is off.
2001 Nov 20
0
PATCH: Fixing last/utmpx for Solaris
In case it is any help, here is the patch against openssh-3.0.1p1 that corrects the problem with last reporting on Solaris that I sent to the list a week or so ago against 3.0p1. There was no conversation about this aside from Rip Loomis' comment about including it to support BSM auditing - does this present a problem for other OSes to include the ut_name field in the utmpx entry? Should this
2002 Jan 29
0
[Bug 84] New: last command provides incorrect information on Solaris 8
http://bugzilla.mindrot.org/show_bug.cgi?id=84 Summary: last command provides incorrect information on Solaris 8 Product: Portable OpenSSH Version: -current Platform: UltraSparc OS/Version: Solaris Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org
2002 Dec 29
0
[Bug 460] New: ut_addr_v6 not used
http://bugzilla.mindrot.org/show_bug.cgi?id=460 Summary: ut_addr_v6 not used Product: Portable OpenSSH Version: 3.5p1 Platform: All URL: http://bugs.debian.org/167867 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at
2001 Nov 15
1
Patch for "last" providing incorrect information on Solaris 8
I have put together a simple set of diffs that corrects the problem described by Steven Fishback <sfishback at interpath.net> on 10-30 on this list regarding incorrect information reported by last on Solaris. The patches merely pass along the username in the utmpx record for a logout. Is there any reason why this would be a problem with other OSes? If not, maybe this could be rolled into the
2003 May 02
1
loginrec.c license
Hi. I am trying to figure out, is loginrec.c (and loginrec.h) licensed under the 4-point BSD license or one without the advertising clause? I'm developing a small ssh2 server (Dropbear), and curently everything is under MIT/X license. I'd prefer not to have to add any advertising clauses, and reinventing the wheel also seems kind of pointless. Looking at the cvs logs, I can't see any
2000 Aug 30
0
Solaris/IRIX audit support: login.c vs loginrec.c
> -----Original Message----- > From: Rip Loomis [mailto:loomisg at cist.saic.com] > Sent: Wednesday, August 30, 2000 11:52 AM > To: openssh-unix-dev at mindrot.org > Subject: Solaris/IRIX audit support: login.c vs loginrec.c > > Comments requested: > I have internally-generated patches against > commercial SSH 1.2.27 that add full support > for generation of
2001 Aug 21
0
Resend: loginrec.c patch
I'm resending this patch just in case it got lost. The first hunk of the patch fixes a problem with the LOGIN_NEEDS_UTMPX support in that the date was not being set in the logininfo structure (causing wrong timestamps in the "last" log). The second hunk just omits the USE_WTMPX code in the LOGIN_NEEDS_UTMPX section if USE_UTMPX is defined. This prevents duplicate events in the
2003 Feb 12
0
[Bug 492] Spurious error message from loginrec when attempting to login in with the highest uid for the first time.
http://bugzilla.mindrot.org/show_bug.cgi?id=492 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From djm at mindrot.org 2003-02-12 11:58
2014 Oct 18
2
[Bug 2296] New: loginrec.c fails to compile when HAVE_ADDR_V6_IN_UTMP is defined
https://bugzilla.mindrot.org/show_bug.cgi?id=2296 Bug ID: 2296 Summary: loginrec.c fails to compile when HAVE_ADDR_V6_IN_UTMP is defined Product: Portable OpenSSH Version: 6.7p1 Hardware: All OS: All Status: NEW Severity: major Priority: P5 Component: sshd
2014 May 22
0
[PATCH] openssh - loginrec.c - Non-atomic file operations.
Hi all. I rewrited lastlog_openseek function. Now is little more atomic when file operations on lastlog file happens. For more details why separate stat and open isn't so safe please take a look at: http://www.akkadia.org/drepper/defprogramming.pdf Have nice day Robin Hack -------------- next part -------------- diff --git a/loginrec.c b/loginrec.c index 4219b9a..281d650 100644 ---
2014 Feb 24
1
loginrec.c: bug in construct_utmpx() definition?
Hello, I am trying to cross compile OpenSSH_5.8p2 on linux for a powerpc target with uClibc available. My problem is that I get a error when loginrec.c is compiled: openssh/loginrec.c: In function 'construct_utmpx': openssh/loginrec.c:790:10: error: 'ut' undeclared (first use in this function) openssh/loginrec.c:790:10: note: each undeclared identifier is reported only once for
2003 Feb 11
0
[Bug 492] New: Spurious error message from loginrec when attempting to login in with the highest uid for the first time.
http://bugzilla.mindrot.org/show_bug.cgi?id=492 Summary: Spurious error message from loginrec when attempting to login in with the highest uid for the first time. Product: Portable OpenSSH Version: 3.5p1 Platform: ix86 OS/Version: BSDI Status: NEW Severity: trivial Priority: P2