Re: [Pan-users] New file posting feature, broken? Misunderstood?

[Duncan]

walt posted on Mon, 27 Jun 2011 22:40:23 +0000 as excerpted:

> On Mon, 27 Jun 2011 22:13:48 +0000, walt wrote:
> 
>> I haven't read enough code to know where the encoding cache is.
> 
> Well, duh.  I just spotted the brand-new 'encode-cache' directory in
> ~/.pan2, so I don't need to read the code :)
> 
> I just noticed you already said your attachments were plain text.  I see
> that my text attachments are yyEncoded into a multipart/mixed post.
> 
> So far I don't know why my attachments worked and yours didn't, sorry.

You probably don't have a clue why yet (I'll explain), but you just 
provided the hint I needed for my answer! =:^)

Years ago, someone discovered that the pan of the time was letting 
attachments set their own file permissions, including executable.  A 
patch soon appeared that stripped the executable bit, but this was after 
Charles had pretty much disappeared and IIRC before khaley had setup his 
repo, so released pan continued to sit without this "security 
enhancement" for some time.

Meanwhile, I believe I was the one (but it might have been someone else, 
I'm too lazy to go back and check, and don't want to wrongly claim credit 
that might belong to someone else, so do NOT take this as such a claim!) 
that tested and posted that pan did indeed obey its umask, so if that was 
set to mask the executable bit, pan didn't save files with that bit set 
in any case.

It's not much of a leap from combining that history with the fact that 
the executable bit means something vastly different on directories and 
now this NEW information, that pan just created a fresh cache directory, 
to guessing what happened, especially since I've ALSO mentioned before 
that I actually use a small wrapper script to start pan, that takes care 
of setting up various sundry things before doing so.

Connect all those pieces together and what's the very reasonable 
conclusion?  Right.  My wrapper script sets pan's umask to strip the 
executable bit, just in case, and it did just that when it created this 
new directory.  But on directories, the would-be executable bit acts as 
the enter bit, instead.  That is, if it's not set, pan can't actually 
reach into the directory to work with the files there.  That's exactly 
the symptom I'm seeing!

I just checked and indeed, the new dir exists, but doesn't have the 
executable bit set.  I know my problem, now, and how to fix it! =:^)

Thanks for the hint! =:^)

Pan rarely enough creates directories that I forgot about the umask 
thing.  Plus, until now, I didn't know this feature depended on a newly 
created directory, so...  

I expect I'll have no problems once I manually add the execute/enter 
permission.  Thanks again. =^)

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