Bug 1172224
| Summary: | logging into separate files for chrooted users not possible | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Marcel Kolaja <mkolaja> | ||||||
| Component: | openssh | Assignee: | Jakub Jelen <jjelen> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Stanislav Zidek <szidek> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 6.6 | CC: | jjelen, ksrot, luvilla, mkolaja, plautrba, szidek, theinric, tlavigne | ||||||
| Target Milestone: | rc | Keywords: | Patch, Regression, Reproducer | ||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | openssh-5.3p1-108.el6 | Doc Type: | Bug Fix | ||||||
| Doc Text: |
* All the messages obtained from an sftp server when using chroot were logged in the global log file through the sshd server even when a valid socket for logging was available. Now, events from the sftp server can be logged through the socket in chroot and forwarded into an independent log file. (BZ#1172224)
|
Story Points: | --- | ||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2015-07-22 06:46:59 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: | |||||||||
| Attachments: |
|
||||||||
Created attachment 966344 [details]
example sftp.conf for rsyslog7
With regards to the reproduction scenario, it's worth noting that SELinux needs to be configured accordingly or in permissive mode, which I used. Otherwise one finds the following logs and logging does not work properly: Jan 14 15:00:05 rhel6 rsyslogd: cannot create '/chroots/user/dev/log': No such file or directory Jan 14 15:00:12 rhel6 setroubleshoot: SELinux is preventing /sbin/rsyslogd from write access on the directory /chroots/user. For complete SELinux messages. run sealert -l c29228fb-0813-4fe3-b5df-2d5d35f9e755 This is how the chroot environment looks like: [root@rhel6 ~]# ls -dl /chroots/ drwxr-xr-x. 3 root root 4096 Jan 14 16:51 /chroots/ [root@rhel6 ~]# ls -AlR /chroots/ /chroots/: total 4 drwxr-xr-x. 4 root sftponly 4096 Jan 14 16:47 user /chroots/user: total 8 drwxr-xr-x. 2 root root 4096 Jan 14 16:49 dev drwxr-xr-x. 2 user sftponly 4096 Dec 8 13:25 home /chroots/user/dev: total 0 srw-rw-rw-. 1 root root 0 Jan 14 16:49 log /chroots/user/home: total 0 [root@rhel6 ~]# /chroots/user/dev/log is created automatically by rsyslogd. Created attachment 981861 [details]
Proposed dist git patch
Proposed patch which checks if there is syslog socket configured and if so, it tries to log children through it. Otherwise it is using same method as previous versions.
Important part in file session.c
@@ -1785,6 +1785,10 @@ do_child(Session *s, const char *command
/* restore SIGPIPE for child */
signal(SIGPIPE, SIG_DFL);
+ struct stat dev_log_stat;
+ if (lstat("/dev/log", &dev_log_stat) == 0)
+ open_log();
+
if (s->is_subsystem == SUBSYSTEM_INT_SFTP) {
extern int optind, optreset;
int i;
Previous patch was problematic because it was breaking non-chroot setups (I didn't consider it enough before submitting) so I moved open_log as close as possible after chroot to minimize impact on other setups. But it looks like there are few other message falling into the gap between chroot and actual internal-sftp (previously logged with the leaked FD through parent). Can you estimate how large problem can this be for customer or testing? 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://rhn.redhat.com/errata/RHBA-2015-1335.html |
Description of problem: In previous versions of openssh in RHEL 6, it was possible to log chrooted users into separate files. A configured and well working setup stops working, when openssh is upgraded to openssh-5.3p1-94.el6.x86_64. All logs go into one file only (/var/log/secure by default). Version-Release number of selected component (if applicable): openssh-5.3p1-94.el6.x86_64 How reproducible: always Steps to Reproduce: 1. install openssh-5.3p1-94.el6.x86_64 or newer and rsyslog7-7.4.10-3.el6_6.x86_64 2. configure sftp in /etc/ssh/sshd_config in the following way: --snip Match Group sftponly ChrootDirectory /chroots/%u AllowTcpForwarding no ForceCommand internal-sftp -l VERBOSE X11Forwarding no --snip 3. configure rsyslog7, so that attached sftp.conf is included 4. configure user user and group sftponly in the following way: [root@rhel6 ~]# getent passwd user user:x:502:503::/:/bin/false [root@rhel6 ~]# getent group 503 sftponly:x:503: [root@rhel6 ~]# 5. perform an sftp session as user user Actual results: All logs go to /var/log/secure. Expected results: Logs for the session of user user is logged in /var/log/sftp.log. Like this: [root@rhel6 ~]# cat /var/log/sftp.log Dec 8 15:10:27 user sshd[22355]: session opened for local user user from [192.168.200.1] Dec 8 15:10:27 user sshd[22355]: received client version 3 Dec 8 15:10:27 user sshd[22355]: realpath "." Dec 8 15:10:27 user sshd[22355]: stat name "/" Dec 8 15:10:27 user sshd[22355]: realpath "/" Dec 8 15:10:27 user sshd[22355]: stat name "/" Dec 8 15:11:49 user sshd[22355]: session closed for local user user from [192.168.200.1] [root@rhel6 ~]# Additional info: When openssh is downgraded to openssh-5.3p1-84.1.el6.x86_64, the expected behavior is observed. This bug has been introduced with the fix of bug #872169. This is a regression.