Bug 1633756
Summary: | ssh-copy-id does not restore correct selinux context on ~/.ssh | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Geoff Goas <gitman+bugzilla.redhat.com> |
Component: | openssh | Assignee: | Jakub Jelen <jjelen> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 28 | CC: | dwalsh, jfch, jjelen, lkundrak, mattias.ellert, plautrba, tmraz |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | openssh-7.9p1-1.fc29 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2018-11-04 06:50:43 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: |
Description
Geoff Goas
2018-09-27 16:18:44 UTC
Hmm ... the restorecon binary is in /usr/sbin/ for some time already. The thing is that unless you have /usr/sbin/ in your path on your server (there were some changes around this in past in Fedora), it will not work. But the sbin paths are appended for login shells since Fedora 10 [1], but they are not included for non-login shells which is an issue here. The ssh executes the command in non-login shell and therefore the /etc/profile is not executed. So what are our ways out? * Consider using login shell (-l switch to sh). Not sure how portable this is: $ ssh localhost "exec sh -l -c 'echo \$PATH'" [...]/usr/lib64/ccache:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin * Fix the setup package to generate correct path also for non-login shells? This will need some more consideration to make sure we do not break other things by doing so. [1] https://fedoraproject.org/wiki/Features/SbinSanity Thank you for your feedback. I pose the following questions to the general audience: 1. Why does restorecon live in /usr/sbin when super user privileges are not required to use it? 2. Where is the path for non-login shells configured? > 1. Why does restorecon live in /usr/sbin when super user privileges are not required to use it? The sbin directory does contain some other binaries without the requirement to be run with superuser privileges (ifconfig, ...). From man hier, the specification fits: > /sbin Like /bin, this directory holds commands needed to boot the system, but which are usually not executed by normal users. The word _usually_ ... normal users should not need to run restorecon manually. > 2. Where is the path for non-login shells configured? The distinguishing between login and non-login shell is not in path, but in arguments. Adding the -l to sh will make the shell login shell and working as you expect. Sorry, I should clarify for question #2 - PATH is different when using sh -c vs. sh -l. PATH is set by /etc/profile when using sh -l. What sets PATH when using sh -c? If I understand correctly what is going on there, the sshd is setting the path environment variable, which is configured during the configure time in spec file: --with-default-path=/usr/local/bin:/usr/bin \ This environment is passed to the children which invokes sh. The sh does not touch the environment variables at all if it is not a login shell. I assume this turns out as a bug in openssh package that was overlooked during the previous Fedora changes referenced in the previous comments. We should follow the system-wide path settings also in OpenSSH and change the above to --with-default-path=/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin \ Would you like to test the change? This is server change so you need to update server so it will take any effect. Here is a scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=30024415 That fixed it. I created a test user and ran ssh-copy-id. Pub key auth works, and the correct selinux contexts are there. $ ssh localhost "exec sh -c 'echo \$PATH'" /usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin With the spec file being what defines the default path, where is /usr/lib64/qt-3.3/bin coming from in my case? Thank you for patience, testing and verifying that it is indeed the issue. I will fix this in the Fedora soon. The profile.d scripts are for some reasons called from the non-interactive shells so it is appended in one of them: grep -r " PATH=" /etc/profile.d/ Well spotted - $ grep -r " PATH=" /etc/profile.d/ /etc/profile.d/qt.sh: *) PATH=$QTDIR/bin:$PATH ;; Thanks for your time! openssh-7.9p1-1.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-5be740cab4 openssh-7.9p1-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-5be740cab4 openssh-7.9p1-1.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report. |