bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gnulib] clean-temp usage question


From: Eric Blake
Subject: Re: [bug-gnulib] clean-temp usage question
Date: Fri, 06 Oct 2006 06:34:22 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Thunderbird/1.5.0.7 Mnenhy/0.7.4.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Bruno Haible on 10/6/2006 6:14 AM:
> Eric Blake wrote:
>> Hmm.  The gnulib mkdtemp module does not take umask into account.  Neither
>> does the mkdtemp variant of lib/tempname.c.  Shouldn't these modules be
>> guaranteeing that the directory created has full user permissions, in
>> spite of the current umask?  Or is it the caller's responsibility (such as
>> is documented by the mkdir-p module) to ensure that umask is 0 at the time
>> of calling mkdtemp/create_temp_dir/...?
> 
> It is on purpose that these temporary directories are created with mode 700.
> Many people have an umask of 002, which means that they make many of their
> files group-writable, but not all of them. If a temporary directory was
> created with mode 777 & ~002 = 775, anyone in the group could place a
> symlink in the temporary directory, such that when a file is created in
> there, it erase the symlink's target. So an attacker could erase even files
> of mode 600 (private files of the user). This is called a "priviledge
> escalation".

I'm aware of that; I'm asking the reverse.  Suppose the user is perverse
enough (usually, only when trying to hammer out corner cases just like
this ;) to run with a umask of 702 (ie. they want group but not user
privileges).  As written, the current code creates an unusable directory.
 Either we must document that a program that uses the clean-temp module
must change umask, call create_temp_dir, and restore the umask, or we
change mkdtemp to do that on our behalf.  And POSIX requires that mkstemp
create a file that is both readable and writable; if you were to strictly
honor a perverse umask, the mkstemp implementation would violate POSIX.

> 
>>> Would this approach be fine for m4?
>> Yes, having a way to register open fds/open FILES alongside the filenames
>> to delete would be helpful.
> 
> OK. Can you try the patch below?

I'll report that in a separate mail.  There's still some work on my part
to integrate with all these new APIs.

> 
> The answer is that you can currently call at_fatal_signal only once.

Looking at the source code, I'm inclined to disagree - you wouldn't have
gone to all the effort of calling xmalloc and tracking actions_allocated
if it weren't intended to call at_fatal_signal multiple times to register
multiple handlers.  And it further looks like you DO guarantee LIFO
calling order of each fatal-signal handler registration.  So my concern
earlier was a bit unwarranted; the module already behaves as I expected
(modulo the fact that it would be nice to support on_exit semantics by
saving a parameter as well).

> 
>> fwriterror is still controversial for the reasons Paul mentioned
> 
> But I need it in GNU gettext.

I never said you couldn't use fwriterror.  But M4 currently uses the
close-stream module which Paul and Jim maintain, and I am not sure whether
they will be using your proposed patch to use fwriterror instead of fpending.

- --
Life is short - so eat dessert first!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFJk1O84KuGfSFAYARAuGkAJ44Ch7NM8AmOYD3R3Fsjf2EzoPUBgCfaMbc
I3hFBGhwOw4fcEp3SSiYcBI=
=e1kc
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]