[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Pan-users] Re: Save attachment file permissions
From: |
Duncan |
Subject: |
[Pan-users] Re: Save attachment file permissions |
Date: |
Tue, 17 Feb 2009 12:54:36 +0000 (UTC) |
User-agent: |
Pan/0.133 (House of Butterflies) |
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
- [Pan-users] Save attachment file permissions, Paul Crawford, 2009/02/16
- Re: [Pan-users] Save attachment file permissions, Steven D'Aprano, 2009/02/16
- [Pan-users] Re: Save attachment file permissions, Duncan, 2009/02/17
- Re: {FILENAME} [Pan-users] Re: Save attachment file permissions, Paul Crawford (at UoD), 2009/02/17
- [Pan-users] Re: {FILENAME} Re: Save attachment file permissions, Duncan, 2009/02/17
- Re: [Pan-users] Save attachment file permissions, Paul Crawford (at UoD), 2009/02/17
- [Pan-users] Re: Save attachment file permissions, Duncan, 2009/02/18
- Re: [Pan-users] Re: Save attachment file permissions, Paul Crawford (at UoD), 2009/02/18
- [Pan-users] Re: Save attachment file permissions, Duncan, 2009/02/18
- Re: [Pan-users] Re: Save attachment file permissions, Paul Crawford, 2009/02/19
- [Pan-users] Re: Save attachment file permissions, Duncan, 2009/02/19