Paul Crawford <p...@sat.dundee.ac.uk> posted 499a9626.80...@sat.dundee.ac.uk, 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 ab...@giganews 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 mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
