1300700 – screen utility resets umask

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1300700 - screen utility resets umask

Summary: screen utility resets umask

Keywords:
Status:	CLOSED NOTABUG
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	screen
Sub Component:
Version:	7.3
Hardware:	All
OS:	Linux
Priority:	unspecified
Severity:	high
Target Milestone:	rc
Target Release:	---
Assignee:	Vaclav Dolezal
QA Contact:	BaseOS QE - Apps
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:	1420851 1465925 1473612
TreeView+	depends on / blocked

Reported:	2016-01-21 13:46 UTC by dpecka
Modified:	2023-09-14 03:16 UTC (History)
CC List:	4 users (show)
Fixed In Version:
Doc Type:	If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:	2019-02-15 14:13:39 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Description dpecka 2016-01-21 13:46:47 UTC

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

Comment 2 dpecka 2016-01-21 14:51:50 UTC

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 ...

Comment 3 dpecka 2016-01-22 11:45:27 UTC

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

Comment 7 Josef Ridky 2017-10-04 12:49:59 UTC

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.

Comment 8 Josef Ridky 2018-11-07 07:49:45 UTC

Assigning to new maintainer.

Comment 10 Vaclav Dolezal 2019-01-15 14:06:22 UTC

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

Comment 11 Vaclav Dolezal 2019-02-15 14:13:39 UTC

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

Comment 12 Red Hat Bugzilla 2023-09-14 03:16:31 UTC

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days

Note You need to log in before you can comment on or make changes to this bug.