"Paul Crawford (at UoD)" <p...@sat.dundee.ac.uk>
posted 499afa13.3030...@sat.dundee.ac.uk, excerpted below, on Tue, 17 Feb
2009 17:55:31 +0000:
> Dear Duncan,
>> 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.
That was my intention, get a workaround out there for folks to use --
while knowing it's a workaround with certain side-effects.
> Irrespective of what POSIX says, this is just too dangerous and against
> the ethos of 'safe by default' that should be the norm.
Absolutely agreed.
> 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!
That's the oft-cited idea.
> 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)
I found that in the my search as well, but I lost the trail trying to
find where and whether pan used that library in that way, or whether it
used something else (like the gmime uue and yenc functionality, which I
found as well, it likely didn't have yenc tho back when Charles started
using uudeview code, FWIW, MIME doesn't include file permissions info,
only yenc and uue do).
... continuing the quote I abruptly severed for the above comment...
> 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.
Looks good, but I'm not coder enough to verify whether it actually
applies to pan code...
> If anyone *really* wanted strict posix behaviour, it could be controlled
> in some config menu with a suitable dire warning about the implications.
I don't believe an option is even appropriate for pan. Keep in mind that
UUE was developed for mail, where between trusting users it arguably made
sense. However, the default if not specified/invalid 644 perms look like
the most reasonable mandatory place to start, for a news client, modified
by the umask of course, and should have been even back then, POSIX spec
(which probably came AFTER UUE was first used in news) or no POSIX spec.
>> DO note, however, that [the umask masked executable bits workaround]
>> 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.
>
> It is not ideal for that reason, and also we should be looking at making
> Pan safe in the default installation for all users!
Absolutely. It was offered purely as a workaround until an appropriate
patch can be found, merged, and distributed thru whoever's supplying the
binaries people are using.
--
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
