Re: [Pan-users] Save attachment file permissions

[Paul Crawford (at UoD)]

Dear Duncan,
> But where is your umask set, and would however you invoke pan get that 
> same umask or not?  IOW, presumably you start pan from a desktop menu 

I did not check that, but given that 'touch' from terminal, Opera and 
Thunderbird all do the same, I guess it is 022 for all (not sure if I 
can change all in *one* place though!)

> entry (unless you're like me and have the menu entry actually start a 
> script that sets a few things before pan itself starts).  Depending on 
> how you're setup, such desktop entries may not get the same umask and 
> environment as you will at a shell prompt.  This is perhaps more likely 
> if you login to your desktop using a graphical dm such as xdm/kdm/gdm/
> etc, than if you login in a text VT and issue startx or similar to start 
> your DE of choice, since the latter will be a direct child of your login 
> shell while the former bypasses it.
>
> FWIW, I just changed my pan starter script to set the umask to 0137 
> before it starts pan, and test-saved that same attachment after 
> reinvoking pan with the new umask, and it honored it, with permissions 
> set 0640 on the same executable that was set 750 in my first test.  So 
> pan DOES seem to honor umask (no matter WHAT the POSIX manual says about 
> uudecode's behavior, see my immediately previous post).

That is a solution, and better than nothing pending a proper security 
hold fix for this.

Irrespective of what POSIX says, this is just too dangerous and against 
the ethos of 'safe by default' that should be the norm.

Without wishing to sound like a techno-snob, if anyone can't master 
chmod and know why, that sure as hell should not be running stuff 
decoded from email/newsgroups!

> So regardless of whether it's pan or a library pan uses doing it, we know 
> know that (1) it's definitely pan as in-memory doing it, and (2), we now 
> have a workaround to prevent it -- set the umask appropriately before 
> starting pan.

After a little searching I found that line 969 of uulib/uulib.c has:

  if ((fildes = open (uugen_fnbuffer,
                      O_WRONLY | O_CREAT | O_BINARY | O_TRUNC,
                      (uu_ignmode)?0666:thefile->mode)) == -1) {

Where it creates the file with the appropriate mode settings. I think 
open() honours umask so that would agree with what you find.

There is a uu_ignmode variable (global to that library) that would do 
what we wish if set, it can be configured by a call to:

UUSetOption (int option, int ivalue, char *cvalue)

such as

UUSetOption (UUOPT_IGNMODE, 1, NULL);

The UUSetOption() function appears to only be used in tasks/decoder.cc 
(line 137) for an altogether different function.

My suggestion is the above 'ignore mode' should be called at the program 
launch (early in gui/pan.cc perhaps?) to revert to 'safe' behaviour.

If anyone *really* wanted strict posix behaviour, it could be controlled 
in some config menu with a suitable dire warning about the implications.

> DO note, however, that this WILL cause "interesting" behaviour if pan 
> needs to create a directory, since for directories, the execute bit has a 
> different meaning.  So don't go doing this and then telling pan to save 
> files into dirs that don't yet exist, 'cause it's not going to work.  But 
> as long as the dirs already exist (or you create them using another 
> program before pan gets to that point) and pan is already setup and 
> configured so it's not trying to create new config dirs, you shouldn't 
> have a problem, and pan will work properly while honoring umask to cancel 
> execute bits on what it saves, if that's what you have pan's inherited 
> umask set to do.

It is not ideal for that reason, and also we should be looking at making 
Pan safe in the default installation for all users!

Regards,
Paul