-----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 [EMAIL PROTECTED] -----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-----
