62993 - signature file can't be a named pipe (or /proc/uptime)

Status: NEW

(MailNews Core :: Backend, defect, P3)

Description

[(not reading, please use [e-mail] instead)]

from n.p.m.mail-news:

"You can with 4.x as well as other mail programs but Mozilla doesn't like it.
It does something that breaks the pipe so the writer process dies. That's ok
the first time you tro to send a message but, of course, all subsequent ones
freeze Mozilla; in fact, the entire process freezes not just the compose
window."

adding shaver to the cc list, as I know he uses this.

this would be linux only.

Comment 1

[tenthumbs]

So I would be the person quoted. I guess I should just file bugs without
worrying about whether they're duplicates. :-)

After some trouble getting strace and mozilla to cooperate, the problem is as I
suspected.

stat("/tmp/10/SignatureTest", {st_mode=S_IFIFO|0644, st_size=0, ...}) = 0
stat("/tmp/10/SignatureTest", {st_mode=S_IFIFO|0644, st_size=0, ...}) = 0
open("/tmp/10/SignatureTest", O_RDONLY) = 24
lseek(24, 0, SEEK_CUR)                  = -1 ESPIPE (Illegal seek)
stat("/tmp/10/SignatureTest", {st_mode=S_IFIFO|0644, st_size=0, ...}) = 0
close(24)

It looks like mozilla doesn't check for a fifo on the stat and it doesn't handle
ESPIPE gracefully.

I will attach a simple test perl script. I borrowed most of it from "man
perlipc." It may come in handy.

Comment 2

[tenthumbs]

Attachment: test perl script

Comment 3

[(not reading, please use [e-mail] instead)]

weird, /proc/uptime doesn't work either.  I don't crash, but no signature.

cc'ing andrew, he might help me out on this one.

ls -al /proc/uptime 
-r--r--r--   1 root     root            0 Dec 18 23:10 /proc/uptime

Comment 4

[tenthumbs]

A stat on a named pipe returns meaningless values for st_size. It
might be 0 or the value from a previous read. If you open a named
pipe for reading and then do a fstat, st_size becomes slightly more
useful. It will be the amount of data available up to a max of
PIPE_BUF so you can't rely on it.

The /proc fs is special (read crock). Although /proc/uptime, for
example, claims to be a regular file both stat and fstat return
st_size = 0.

Mozilla gets really confused by all this because it implicitly
assumes st_size is meaningful. It also tends to assume that only
directories and regular files exist.

Now cat gets around this by just opening a file, doing a fstat to
get st_blksize (not st_size), and just reading st_blksize chunks
until it gets an EOF. In other words, it treats all files as
streams. Actually, it eliminates directories but not much else.

That's an appealing idea. One would think that Mozilla knows how to
deal with streams. Is it feasible, though. It would mean buffering
the signature file and examining the buffer for mime type. This is
also a significant change and there might not be time to do this
right, although it will have to be done eventually. Users will
rightly consider Mozilla broken if cat reads a file but mozilla
doesn't.

Comment 5

[Thibault G.]

*** Bug 95915 has been marked as a duplicate of this bug. ***

Comment 6

[Thibault G.]

I do consider that mozilla is broken if I can
read something with cat, but not mozilla ...

Don't you think it is time to do it now ?

I think it should at least (for now) be a little fixed in order
to avoid that damned freezes ...

Comment 7

[Thibault G.]

It seems that my last comment doesn't "traduce" my thought correctly :
sorry about that, and sorry to all of you who may have felt sworn.

I just wanted to tell you guys that I think this bug need a fix.
I thought adding a comment, even not very useful :)), would remind you
of that bug. But my comment was quite incorrect ... sorry again.

I know that you do it on your free time, and I know that you don't
have unlimited free time.
Thanks for all you do : I use Mozilla a lot, it keeps on improving,
and I hope it will replace one day that ugly IE :)) !

Comment 8

[s.wong]

Attachment: signature program that uses a piped .signature

Comment 9

[s.wong]

0.9.3 does not takes a piped signature at all. This is used in programs such as
signature, which generates a new sig everytime the pipe is accessed. It works
with all mailers except Pine and mozilla. The program is attached and it can
also be found on http://freshmeat.net. Here's something from its man page:

       Pine  fails  to  play  properly with signature, because an
       fstat(2) on the signature FIFO prior to opening it returns
       0 in stat.st_size, causing Pine to open and close it with­
       out actually reading  anything.  This  causes  a  SIGPIPE,
       which signature calmly ignores.

This should because if cat and other mailers can use this, so should mozilla.

Comment 10

[Sheela Ravindran]

*** Bug 103113 has been marked as a duplicate of this bug. ***

Comment 11

[R.K.Aa.]

*** Bug 111607 has been marked as a duplicate of this bug. ***

Comment 12

[R.K.Aa.]

*** Bug 115241 has been marked as a duplicate of this bug. ***

Comment 13

[R.K.Aa.]

*** Bug 113640 has been marked as a duplicate of this bug. ***

Comment 14

[R.K.Aa.]

*** Bug 145335 has been marked as a duplicate of this bug. ***

Comment 15

[R.K.Aa.]

*** Bug 147708 has been marked as a duplicate of this bug. ***

Comment 16

[Evan Torrie]

This also occurs on FreeBSD (I'm sure on any Unix type system).  In my case, 
I'm using signify (http://www.debian.org/) with its --fifo mode to create a 
named pipe for .signature.

Comment 17

[R.K.Aa.]

*** Bug 151613 has been marked as a duplicate of this bug. ***

Comment 18

[Jo Hermans]

*** Bug 163831 has been marked as a duplicate of this bug. ***

Comment 19

[hennessy]

Still not working in 1.1 (2002072208)

Any news?

Comment 20

[Pádraig Brady]

Attachment: 1 line patch to fix and also limit sigs to 4K

This patch just reads the first 4K from the file.
Should work for proc/named pipes/...

Comment 21

[tenthumbs]

I don't think this will work. Pipes are streams and you have to read until EOF 
or you'll have problems. If you close a pipe prematurely then the SIGPIPE 
signal is sent to the writing process (the other end of the pipe). If the 
writer isn't expecting SIGPIPE it will be killed. If that happens then the 
next time mozilla reads from the pipe it will hang. Users will rightly 
complain about mozilla.

You either should deduce what type of file you're reading from and take 
appropriate action or just read until EOF throwing out what you don't want.

BTW, the browser has no trouble reading from pipes which just makes mailnews 
look silly.

Comment 22

[Pádraig Brady]

I see what your saying but I don't aggree.

If a daemon's sole purpose is to write to a named pipe
and can't handle SIGPIPE then all bets are off. SIGPIPE 
could be generated in many instances. This will only
happen if the sig is bigger than 4K and SIGPIPE is quite
polite I think for something trying to send me a 4K sig :-)

Conversely though, mozilla will hang if there is nothing
writing to the pipe, so perhaps a timeout is appropriate?

Anyway, please apply the simple patch, as it fixes 3 problems:

1. reading from /proc/uptime
2. reading from named pipes (rotating signatures)
3. reading very large signatures

Comment 23

[tenthumbs]

A well-behaved app does *not* throw signals at other apps just because it 
wants to. Trying to blame some other app because mozilla is sloppy is no 
excuse.

Nost people who try named pipes probably get their information from the perl 
example (man perlipc). Mozilla should work with that. Your patch will not.

Timing out may be very hard. :-) You have to open a file in non-blocking mode 
and then use select or poll to see if it's ready. Your patch needs to address 
that.

Comment 24

[Pádraig Brady]

Questions:

What does perlipc do if mozilla crashes while it's writing
(about as likely as writing more than 4K sig in fairness).
I.E. I still don't think we should worry about sending
SIGPIPE to the writer if it gives us more than 4K.

If we were to do a timeout, what would it be? 1 second?

Why would the socket need to be nonblocking? We could
just select() the blocking fd as the thread doesn't
need to do anything else

Comment 25

[Shawn Willden]

Is there any progress on this? 

Comment 26

[Carl-Daniel Hailfinger]

Attachment: alternative patch, doesn't change behaviour for regular files

Attached another less invasive patch for discussion.
Might be worthwhile getting this in 1.4beta

Comment 27

[Carl-Daniel Hailfinger]

Patch is available.

Could someone please add
-whiteboard: [patch]
-keywords: 4xp

Comment 28

[Andrew Schultz]

only drivers can set (+) blocking flags.  you can request (?) them.

Comment 29

[The Anarcat]

What are we waiting for? Isn't this ready and patched?

I'd really like to have random sigs in Mozilla.

Comment 30

[Scott MacGregor]

this is not a feature we'll bbe evaluating for a security release. minusing.

Comment 31

[Magnus Melin [:mkmelin]]

*** Bug 344018 has been marked as a duplicate of this bug. ***

Comment 32

[Magnus Melin [:mkmelin]]

None of those patches are working for me. Still just a hang:(

Comment 33

[(not reading, please use [e-mail] instead)]

sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.

Comment 34

[Serge Gautherie (:sgautherie)]

Filter on "Nobody_NScomTLD_20080620"

Comment 36

[Iain]

Using Shredder version 3.0a2 (2008072418) binary, the bug is kind-of fixed!

When using a fifo as a signature, Shredder doesn't attach any output of the fifo to my message, nor does it lock up.  If I change the fifo to a text file, it works as expected.

thanks.

Comment 37

[Wayne Mery (:wsmwk)]

(In reply to comment #36)
> Using Shredder version 3.0a2 (2008072418) binary, the bug is kind-of fixed!
> 
> When using a fifo as a signature, Shredder doesn't attach any output of the
> fifo to my message

patch is obsolete?

Comment 38

[Magnus Melin [:mkmelin]]

Comment on attachment 120036 [details] [diff] [review]
alternative patch, doesn't change behaviour for regular files

Yes, and as i recall, it didn't work for me back when it applied.