Assertion failure when appending to log file

[secure bit]

putty suddenly exit with the following error message when trying to connect over http proxy :

putty: ../unix/uxmisc.c:144: f_open: Assertion `mode[0] == 'w'' failed.
Aborted (core dumped)
I am using hardy heron beta, and I am very up to date

my kernel is 2.6.24-15-generic #1 SMP Fri Apr 4 03:48:31 UTC 2008 i686 GNU/Linux, but the problem happened even at the previous kernel version (before I've updated)

[Jacob Nevins (0jacobnk-ulp)]

> putty suddenly exit with the following error message when trying to
> connect over http proxy :
>
> putty: ../unix/uxmisc.c:144: f_open: Assertion `mode[0] == 'w'' failed.
> Aborted (core dumped)

This can happen if you've enabled PuTTY's logging and it tries to append
to a file ('What to do if the log file already exists' either set to
'Always append to the end of it', or 'Ask the user every time' and the
user hit 'Append').

I don't think it's got anything to do with use of an HTTP proxy.

Can you confirm that this is what you're doing?

The bug I describe was introduced in 0.59 (r7084). It's happening
because PuTTY sets the 'is_private' flag to uxmisc.c:f_open() when
opening a log file, in an attempt to keep session logs private (because
that seemed like a good idea at the time; r7084 was mainly about
permissions on puttygen-generated keypairs). However, f_open() as
currently written fails the assertion above when presented with a file
mode of 'a' (append).

It's not clear to me what f_open() _should_ do in this situation
(although we shouldn't die, of course). The options are:

 - explicitly chmod the existing file to make it private (prevents users
   sharing a growing logfile);

 - carry on regardless of the existing file's permissions (risks
   disclosing sensitive data);

Or we could change our mind about session logs being private, and revert
to that being the user's responsibility.

> I am using hardy heron beta, and I am very up to date
>
> my kernel is 2.6.24-15-generic #1 SMP Fri Apr 4 03:48:31 UTC 2008 i686
> GNU/Linux, but the problem happened even at the previous kernel version
> (before I've updated)

I don't think any of those things is significant.

> --
> putty shutdown when trying to connect over http proxy
> https://bugs.launchpad.net/bugs/212711
> You received this bug notification because you are subscribed to putty
> in ubuntu.

[secure bit (ahmad-hamad-777)]

this is true, I have chosen always to append the log, however the problem
disappears when I chose always overwrite, so I can't append ?

On Mon, Apr 7, 2008 at 10:34 PM, Jacob Nevins <
<email address hidden>> wrote:

> > putty suddenly exit with the following error message when trying to
> > connect over http proxy :
> >
> > putty: ../unix/uxmisc.c:144: f_open: Assertion `mode[0] == 'w'' failed.
> > Aborted (core dumped)
>
> This can happen if you've enabled PuTTY's logging and it tries to append
> to a file ('What to do if the log file already exists' either set to
> 'Always append to the end of it', or 'Ask the user every time' and the
> user hit 'Append').
>
> I don't think it's got anything to do with use of an HTTP proxy.
>
> Can you confirm that this is what you're doing?
>
> The bug I describe was introduced in 0.59 (r7084). It's happening
> because PuTTY sets the 'is_private' flag to uxmisc.c:f_open() when
> opening a log file, in an attempt to keep session logs private (because
> that seemed like a good idea at the time; r7084 was mainly about
> permissions on puttygen-generated keypairs). However, f_open() as
> currently written fails the assertion above when presented with a file
> mode of 'a' (append).
>
> It's not clear to me what f_open() _should_ do in this situation
> (although we shouldn't die, of course). The options are:
>
> - explicitly chmod the existing file to make it private (prevents users
> sharing a growing logfile);
>
> - carry on regardless of the existing file's permissions (risks
> disclosing sensitive data);
>
> Or we could change our mind about session logs being private, and revert
> to that being the user's responsibility.
>
> > I am using hardy heron beta, and I am very up to date
> >
> > my kernel is 2.6.24-15-generic #1 SMP Fri Apr 4 03:48:31 UTC 2008 i686
> > GNU/Linux, but the problem happened even at the previous kernel version
> > (before I've updated)
>
> I don't think any of those things is significant.
>
> > --
> > putty shutdown when trying to connect over http proxy
> > https://bugs.launchpad.net/bugs/212711
> > You received this bug notification because you are subscribed to putty
> > in ubuntu.
>
> --
> putty shutdown when trying to connect over http proxy
> https://bugs.launchpad.net/bugs/212711
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Jacob Nevins (0jacobnk-ulp)]

The described problem definitely exists (in Ubuntu and upstream).

[korziner (korziner)]

I can confirm.
2.2.24-22-generic
putty_0.60-2build1_i386
Enabled PuTTY's logging and it tries to append to a file ('What to do if the log file already exists' set to 'Always append to the end of it'.
"putty: ../unix/uxmisc.c:144: f_open: Assertion `mode[0] == 'w'' failed"

I do not really need adding to one log file. How could we force putty log to different files with names, contaning a date and time of session start?

[korziner (korziner)]

As a workaround:
Log to /home/ubuntuser/puttylogs/putty&Y&M&D&T.log
"Always owerwrite it" instead of "append". Than issue a command:
cat /home/ubuntuser/puttylogs/putty*.log > /home/ubuntuser/puttylogs/putty.log

[Jacob Nevins (0jacobnk-ulp)]

Fixed upstream in r8461, by no longer attempting to keep the log file private in any circumstances. (Which probably thus wants advertising in the changelog.)

[Launchpad Janitor (janitor)]

This bug was fixed in the package putty - 0.60+2009-04-05-1

---------------
putty (0.60+2009-04-05-1) unstable; urgency=low

  * New experimental development snapshot.
    - Stop attempting to make session logs private on Unix. This was
      introduced in r7084 at the same time as sensible permissions when
      writing private key files; however, it causes an assertion failure
      whenever an attempt is made to append to an existing log file on Unix,
      and it's not clear what "is_private" *should* do for append, so revert
      to log file security being the user's responsibility (LP: #212711).
    - Cope with GTK+ 2.0 encoding keypress strings in the current locale
      rather than in ISO-8859-1 (closes: #517535).

putty (0.60+2009-02-22-1) unstable; urgency=low

  * New experimental development snapshot.
    - Uses GTK+ 2.0 (closes: #516641, LP: #271277) and as a result supports
      Unicode window titles (LP: #48781).
    - Fixes handling of trailing CR in key files (closes: #414784).
  * Disabled upstream Kerberos support for now, as it produces unwanted
    linkage in pterm and other binaries.

 -- Ubuntu Archive Auto-Sync <email address hidden> Wed, 29 Apr 2009 12:08:57 +0100