On Mon, 23 Oct 2006 11:13:38 +0000, Duncan wrote:
> "Jack Cuyler"
> <[EMAIL PROTECTED]> posted
> [EMAIL PROTECTED], excerpted below, on Sun, 08 Oct 2006 19:13:43
> +0000:
>
>> +TMP=${TMP:-/tmp}
>> +TEMPFILE=${TMP}/panpost.$(date +%Y%m%d%H%M%S%N)
>
> OK, I'm looking at this in a bit more depth now, and like it except that
> I'm not satisfied with the safety of the bit above. For
> reference, see "Safely Creating Temporary Files in Shell Scripts"
> http://www.linuxsecurity.com/content/view/115462/151/
>
> FWIW, I just now did the research on that myself. I knew there was an
> issue and had basically flagged it in my head as something to look into
> before I ever started creating tmpfiles in public scripts. Now that I
> actually have a use for the info and should therefore retain it better, a
> bit of googling to the rescue, as I expected. =8^)
>
> Given that the sig should be reasonably small, I'll probably implement the
> solution covered in section 3.1 of the above document -- don't use a
> tmpfile for the sig at all, instead copying it to an environmental
> variable.
Defining a umask should take care of any security concerns:
umask 177
TMP=${TMP:-/tmp}
etc etc
I wasn't aware of the mktmp command when I posted, but the date command in
the variable name will take care of any race conditions, unless two
instances are run at the same nanosecond. It's possible, I guess, but
highly unlikely.
Either way, it's just as simple to use variables instead. Just remember
to quote them when echo-ing back, or there will be no newlines.
> Not that I had to explain it as I could have just implemented it.
> However, this is a learning experience for me, and since you were nice
> enough to provide the patch with the sed commands so I don't have to
> slough thru figuring out sed well enough to do it myself, I thought I'd
> pass the tip on safe tmpfile creation back. =8^)
>
> FWIW, a guy named Bruno Gnecco mailed me another suggestion as well. By
> quoting the ATFILE in the following lines (original version without your
> patch) as shown, the path can be made space-safe. I /think/ it should
> actually be single-quotes, thus avoiding shell-expansion of any other
> strange characters, which should make it safe for them at the same time.
> However, I've not (yet) tested either way and he had presumably tested the
> double-quoted way, so...
>
> 117: while [ ! -r "${ATFILE}" ]; do
> 126: uuenview -${ENCODE} "${ATFILE}" >> ${BODYFILE}
Single quotes will not allow the variable to be expanded at all.
'${ATFILE}' will return ${ATFILE}, not the variable's value. Double
quoting will work even if the file has odd characters.
> I expect to have a rollup release with both of those and a bit more proper
> license implementation (likely either including the text of the GPL as
> comments, since it's a single file distributed, which seems to be the FSF
> recommendation tho I haven't researched that in depth for scripts yet --
> but that's a bunch of text which would double the size, thus why I
> consider the GPL somewhat unappropriate for a script -- or perhaps switch
> to CC Attribution/share-alike) soon. I wanted to do it last week but last
> week ended up being a mad week, so skipped it.
>
> Having whet my appetite with this, I'm thinking more and more seriously
> about trying for a newspost front-end as well. Now /that/ would be
> something quite useful, given how far out of date the existing KDE/GNOME
> front-ends for it are, and that it would likely be of interest to more
> than just pan users. It's possible it could get distribution attention,
> so getting stuff like license issues figured out with pan-attach-kd is
> probably a useful practice run. =8^) (Hmm... maybe I should actually
> check to see if there's already a project of the same nature around first.
> <g>)
You inspired me as well -- I started working on a newspost frontend a few
days after you posted this. Shoot me an email off list, if you'd like
([EMAIL PROTECTED]). What I have works for the
most part (uses zenity, but it should be trivial to translate it to kde).
Of course, it could use a lot of security checking/polishing/etc.
I'd be happy to have another pair of eyes take a look and throw around
some ideas.
--
Cheers,
Jack
I WILL NOT XEROX MY BUTT
I WILL NOT XEROX MY BUTT
I WILL NOT XEROX MY BUTT
I WILL NOT XEROX MY BUTT
Bart Simpson on chalkboard in episode 7F01
_______________________________________________
Pan-users mailing list
Pan-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/pan-users
