Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

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 1418062

Summary:	openssh package openssh-6.6.1p1-33.el7_3 does not resolve chroot permission denied status.
Product:	Red Hat Enterprise Linux 7	Reporter:	Matt Mezynski <mmezynsk>
Component:	openssh	Assignee:	Jakub Jelen <jjelen>
Status:	CLOSED ERRATA	QA Contact:	Stefan Dordevic <sdordevi>
Severity:	high	Docs Contact:	Mirek Jahoda <mjahoda>
Priority:	unspecified
Version:	7.3	CC:	nmavrogi, sdordevi
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	openssh-7.4p1-2.el7	Doc Type:	Bug Fix
Doc Text:	Configurations that depend on chrooting in user-non-searchable paths now work properly In Red Hat Enterprise Linux 7.3, the chroot process in the OpenSSH tool had been changed to help harden the SELinux system policy, and root UID was dropped before performing chroot. Consequently, existing configurations that depend on chrooting in user-non-searchable paths stopped working. With this update of the _openssh_ packages, the change has been reverted. Additionally, the problem has been fixed in the SELinux system policy by allowing confined users to use OpenSSH chroot if the administrator enables the `selinuxuser_use_ssh_chroot` boolean. The described configurations now work in the same way as in Red Hat Enterprise Linux 7.2.	Story Points:	---
Clone Of:
Clones:	1435264 (view as bug list)		Environment:
Last Closed:	2017-08-01 18:42:47 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1420851, 1435264, 1435289

Description Matt Mezynski 2017-01-31 18:23:11 UTC

Description of problem:
The package release as a resolution to Bug 1398569 still faces Permission denied status in the chroot environment.

Version-Release number of selected component (if applicable):
RHEL 7.3
openssh-6.6.1p1-33.el7_3 

How reproducible:
Always

Steps to Reproduce:
1. Install openssh-6.6.1p1-33.el7_3
2. root uid is now dropped before doing chroot 
3. encounter permission denied messages

Actual results:
chroot privileges not respected 

Expected results:
chroot privileges should be respected 

Additional info:

Comment 2 Jakub Jelen 2017-02-02 11:10:38 UTC

As already pointed out in the personal mail it is certainly different behavior caused by the fix in the bug #1357859.

The root cause is that we now drop root UID before doing chroot so the target user does not have permissions to stat all parts of the chroot directory.

As a workaround we can set the x permission for others on all parts in the path to the chroot.

For RHEL7.4 we will have to investigate if we will revert this feature or will be able to resolve it in some other way.

Comment 3 Matt Mezynski 2017-02-02 18:48:34 UTC

Hopefully we can approximate the chroot behavior from RHEL 6 in in the 7.4 release?

Comment 5 Jakub Jelen 2017-02-06 08:19:42 UTC

Thank you for verifying the workaround. I will keep you updated on how we are going to fix that as soon as possible.

Comment 10 errata-xmlrpc 2017-08-01 18:42:47 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:2029