Bug 1172224 - logging into separate files for chrooted users not possible
Summary: logging into separate files for chrooted users not possible
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: openssh
Version: 6.6
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Jakub Jelen
QA Contact: Stanislav Zidek
URL:
Whiteboard:
Keywords: Patch, Regression, Reproducer
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-12-09 16:22 UTC by Marcel Kolaja
Modified: 2019-04-16 14:27 UTC (History)
8 users (show)

(edit)
* 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)
Clone Of:
(edit)
Last Closed: 2015-07-22 06:46:59 UTC


Attachments (Terms of Use)
example sftp.conf for rsyslog7 (139 bytes, text/plain)
2014-12-09 16:23 UTC, Marcel Kolaja
no flags Details
Proposed dist git patch (1.91 KB, patch)
2015-01-20 14:50 UTC, Jakub Jelen
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:1335 normal SHIPPED_LIVE openssh bug fix and enhancement update 2015-07-20 17:52:59 UTC

Description Marcel Kolaja 2014-12-09 16:22:24 UTC
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.

Comment 1 Marcel Kolaja 2014-12-09 16:23:41 UTC
Created attachment 966344 [details]
example sftp.conf for rsyslog7

Comment 4 Marcel Kolaja 2015-01-14 14:13:39 UTC
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

Comment 5 Marcel Kolaja 2015-01-14 16:03:51 UTC
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.

Comment 9 Jakub Jelen 2015-01-20 14:50:09 UTC
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;

Comment 33 Jakub Jelen 2015-03-03 16:54:59 UTC
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?

Comment 42 errata-xmlrpc 2015-07-22 06:46:59 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://rhn.redhat.com/errata/RHBA-2015-1335.html


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