[Pan-users] Re: Save attachment file permissions

[Duncan]

Steven D'Aprano <address@hidden> posted
address@hidden, excerpted below, on  Wed, 18 Feb 2009
00:23:09 +1100:

> Overheard in the boardroom of Ford Motor Company:
> 
> "Oh no, you can't blame our SUVs for their poor fuel economy or for
> producing vast amounts of carbon dioxide, carbon monoxide, nitrous
> oxide, sulphur dioxide and benzene. It's not the fault of the SUV, it's
> the fault of the *engine*."
> 
> *wink*

Yah, yah.

> I'm actually relieved. It sounds like it's not a deliberate decision to
> change the permission, just a bug caused by (inadvertent?) reliance on a
> standard invented when programmers were even more trusting and naive
> than they are now. In other words, an ordinary security hole, not a sign
> of moral degeneracy :)

I've been looking around.  pan used some gmime stuff, but also includes 
its own copy of uudeview code, apparently modified to be used by pan.  
(Such "internal" versions are normally quite discouraged by the 
community, because if there's a security vuln, it's much more difficult 
to ensure all packages shipping internal versions of the same code are 
updated than it is to update a single system-wide shared version.  
However, if the modifications are big enough, upstream isn't cooperative, 
and there aren't any easily substituted alternatives, it may be 
necessary.  I don't know why Charles ships it internal but perhaps he had 
to modify it for use as a library instead of as the stand-alone apps the 
package normally ships as.)

uudeview is a uudecode/uuencode compatible replacement that handles yenc 
also.  I have the package installed separately here.  Anyway, the 
uudeview command includes a command line option -m.  Here's the manpage 
bit on it (paragraph quote):

Ignore  file  mode.  Uuencoded and xxencoded files have the original file 
permissions stored on the begin line. Unless this option is given, 
UUDeview will restore them without checking if they are sensible. With
this option, the permissions are reset to a default of 0666.

I see the implementation of that option still in the code shipped with 
pan, but don't know how it relates to whatever functions pan might call 
or include from that code.  I don't claim to be a C/C++ coder so there 
are limits to how well I can read and parse/interpret source.

I also see this in the POSIX Programmer's Manual (man section 1P) entry 
for uudecode (partial paragraph quote):

The file access permission bits and contents for the file to be produced 
shall be contained in that data. The mode bits of the created file (other 
than standard output) shall be set from the file access permission bits 
contained in the data; that is, other attributes of the mode, including 
the file mode creation mask (see umask()), shall not affect the file 
being produced.

OUCH!  According to that, even letting umask affect it is a violation of 
the POSIX spec!  OTOH, it does have a Linux implementation disclaimer 
saying Linux behavior may be different or the interface may not exist...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman