[Pan-users] Re: Save attachment file permissions

[Duncan]

Paul Crawford <address@hidden> posted
address@hidden, excerpted below, on  Tue, 17 Feb 2009
10:49:10 +0000:

> Dear Duncan,
>> The above claim, that under Linux, files are created with default
>> permission 644, is simply not accurate.  It's too general (perhaps
>> certain distributions, not "Linux") and lacks a description of the
>> vital role umask plays in determining default file permissions.
> 
> I have just tried sending a .exe file to myself and with Thunderbird it
> is saved with a 644 mask, which is what I expected.
> 
> I can also confirm that saving the putty.exe Windows Telnet/SSH client
> using Opera from
> http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html also
> results in the expected 644 permission settings.
> 
> All on the same Ubuntu 8.10 box, so it looks very much like Pan is at
> fault here (or perhaps is just not being more proactive in stopping a
> stupidly "helpful" system?).

I decided I was curious enough to test this myself using the howard-stern 
group post specified earlier.

I fired up my pan.test instance for this since I don't have the group 
subscribed and I didn't want to mess up the files my regular instance...

After finding the group and then the thread, then confirming the right 
post, I downloaded (to cache, my default download action) it, then when 
it was all in cache, hit save, and selected save both text and 
attachments, since I wanted to investigate what on the raw message 
contains if the attachment should prove to save with the executable bit 
set while other messages don't.

Resulting permissions on the executable:

0750 -rwxr-x---

OK, the permissions honor umask (0027), but the executable bit is set if 
allowed.  Hmm...

The permissions on the text file:

0640 -rw-r-----

That's the expected, again honoring umask, but NOT setting the exe bit 
where allowed, as expected.

Let's see what it does on a normal data attachment, using a nice small 
single-part 889 KB MP3 post from the same group, the attachment...

0640

A multi-segment, the attachment:

0640

OK, looks like /something/ is deciding that the .exe needs the executable 
bit set.  Looks like I /might/ eat a few of those 250 lines of words! =:^)

But we still don't know whether it's pan itself, or simply something in 
gtk that pan doesn't overrule (what I expect, I still see no reason for 
pan to manage permissions itself, but if GTK is doing it by default... or 
it could be another library), or perhaps something in the desktop 
environment (KDE) or something else not yet known.

Meanwhile, taking a look at the raw message...

Interesting, headers indicate Giganews as the originating news server, 
and they don't seem to be forged since the path indicates a direct 
giganews > highwinds-media (my ISP's outsourced news provider) handoff... 
unless it's from highwinds-media itself, which would need more 
verification to know for sure, but it looks authentic.  I wonder if 
anyone's notified address@hidden yet?  They're pretty good nettizens and 
as such will probably yank his account, whoever it was.

User-agent: Microplanet-Gravity

It got apparently got by the Giganews post filter as it has a header for 
that.

It's UUE encoded.  I guess that makes the most sense if the target is the 
widest audience possible.  That's also the info I was looking for.  
Here's the begin line:

begin 755 Private-Amelie-14-27.avi.exe

Note that number after the begin.  Look familiar?  It did to me!  A quick 
google confirms:

>From http://www.lesnikowski.com/uue/

UUE format description:
...
Uuencode (Unix-to-Unix Encode), as its name implies, comes from the Unix 
world. It was commonly used to encode files transmitted from one Unix 
computer to another. 
...
Below [is a UUE example.]

The first line starts with the word "begin".
The "644" represents the Unix file permissions (read/write/execute).
This is largely ignored by other operating systems.
In this example, "a.gif" is the file name.
...
begin 644 a.gif
...
[end web page excerpt]

OK, we now have our "why".  It's because UUE includes perms and they were 
set 755, so our saved file is 755 XOR the umask of, in my case, 0027, 
final result as above, 0750.

But, we still don't know where the code is that's doing it.  Given the 
new info that UUE includes permissions, which I wasn't aware of and is 
frankly a bit scary in today's world (but remember the era in which it 
was invented was the SAME era in which SMTP was created, without an 
authentication mechanism, because everybody just trusted that you'd only 
attempt to connect to and send messages thru servers you had permission 
to use and relaying was fully accepted, and that said messages were 
always legit...), I'll modify my stated suspicion above from GTK to the 
MIME and/or encoding/decoding library, altho I'm not sure what pan 
uses... let's see...

ldd /usr/bin/pan
...
        libgmime-2.0.so.2 => /usr/lib64/libgmime-2.0.so.2...

equery b libgmime-2.0.so.2
[ Searching for file(s) libgmime-2.0.so.2 in *... ]
dev-libs/gmime-2.2.23 (/usr/lib64/libgmime-2.0.so.2 -> ...)

I'm guessing that's what's responsible, as a library, but as I said, 
there's no pan code dealing with permissions -- it's all the library.  
Only now no pan code dealing with permissions means it's not undoing what 
the library (which I'm only assuming is gmime at this point, pending 
research) does, which means the code in the executable binary "pan" is 
not responsible for the executable bit, but the binary as linked in 
memory WILL be, due to the code in the library which is after all only 
implementing the UUE standard which provides for the permission bits, NOT 
to pan code.

So it doesn't look like I'm going to be made to eat some of those 250 
lines now after all, tho only by virtue of the fact that it's not the pan 
code that's doing it but the library. =:^) It's just that pan doesn't 
have code to undo what the library does by default, or to prevent it 
doing it in the first place (say by altering the UUE perms to kill the 
execute bits before feeding it to the decoder), either.

But that has yet to be confirmed, of course.  There's more research to 
do...

-- 
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