[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
restrictive umask vs gnupload
From: |
Jim Meyering |
Subject: |
restrictive umask vs gnupload |
Date: |
Tue, 06 Dec 2011 21:37:56 +0100 |
I use a umask of 077.
That is rather irregular (022 is more common), but for a good reason.
It might have saved me from exploit via at least one flaw (the automake
"dist" abuse CVE).
Anyhow, many tools fail to account for the possibility of a restrictive
umask, and gnupload is one of them.
If I'm not careful, gnupload will create a .sig file that is
neither group- nor world-writable (0600 permissions).
In some contexts, if I upload and preserve those permissions,
the file will be inaccessible.
I have a few ways to avoid that:
- change gnupload to set umask 022
- change gnupload to run chmod go+r on each uploaded file (may not
always be appropriate?)
- temporarily set umask 022 before running gnupload
(which would mean changing the gnupload command that maint.mk emits,
- "remember" always to set permissions of files I'm uploading so that
they include go+r
- set umask 022 via a .gnuploadrc file in every build directory
So far, this happens only when I make gnupload use scp (i.e., not to
ftp.gnu.org).
I'd prefer to change gnupload.
The umask-in-gnupload change would fix it only for .sig,
but unless I'm careful, the .tar.xz file is also go-r,
so from that perspective, the chmod go+r would be better.
You can argue that this whole problem would go away if I
would just use (umask 022; make stable), but that is exactly
the context in which I did not want to use a permissive umask.
However, now that all of my working directories are go-rwx,
it should be mostly moot. But you never know when some tool
you run might decide to create a directory in /tmp ...
Opinions, preferences, "get over it!" ;-)
- restrictive umask vs gnupload,
Jim Meyering <=