Hide Forgot
Hello, I've found a critical security issue, if you have set umask (even in correct way, see https://bugzilla.redhat.com/show_bug.cgi?id=1283670) to some non-default value, the screen utility will always destroy your umask and set some own .. How to reproduce: 1) set in your el6/7 umask to some non-default value eg: $ umask 0077 2) run screen utility by issuing a screen command: $ screen 3) check your umask by $ umask I reproduced this behaviour in el6, el7 and in systems with default settings as well in other systems that were modified according to bug 1283670 .. It happens everywhere. I tried to reproduce this behaviour in suse, debian and solaris, it doesn't happen there and in all other linux/unix systems I have to my disposal screen utility uses umask set for the user .. regards, daniel
I'd like to additionally add the following: my standpoint is: if screen does like that (is affected by this) non-transparently what else is covertly affected by this ? Once you start in el hardening the security in umask area, you are forced to drop defaults and deploy relatively lot of changes .. Generally said, I don't expect that this will change in current el7 release because of changing policy but I hope, that it will leak to fedora and afterwards to future rhel releases ...
Hello again, one more findings, this umask comes from /etc/bashrc (the one from screen) ... in regard to bug 1283670 I even overlooked, that umask is additionally in /etc/bashrc also ... But it's still valid, that you should be able to reproduce it with el6/7 defaults as well as with umask settings moved to pam .. Did another tests, I've put my umask settings in el7 to ~/.profile ... doesn't work either because of .bashrc from SKEL doing (after .profile): if [ -f /etc/bashrc ]; then . /etc/bashrc fi This is ridiculous to re-write umask on N places during the shell invocation. I can unserstand, that umask is in el7 supposed to be set just from ~/.bashrc (not from ~/.profile and not from PAM) but I'd consider this design as broken. Regards, daniel
May I ask you for explanation, why do you think, this issue can be resolved by screen update? (regards to bug 1283670) From my point of view it is correct behavior due your umask setting is valid for your current shell session only. By calling screen command (or bash etc.) you create new shell session with default umask settings.
Assigning to new maintainer.
Hello. Since screen doesn't manipulate its umask (see below), I don't see any problem in screen. umask is set inside bash by sourcing its rc files. Regards, Václav Doležal --- $ umask 0002 $ umask 0077 $ umask 0077 $ screen screen 0:bash$ umask 0002 (screen cmdline): screen bash --noprofile --norc screen 1:bash$ umask 0077 (another term)# cat /proc/`pidof SCREEN`/status |grep Umask Umask: 0077
Since screen doesn't touch its umask (or umasks of its children) and I don't see any thing that screen can do better in this regard, I'm closing this bug. If you disagree with this reasoning, please elaborate on it. Regards, Václav Doležal