[Bug 2681] New: postauth processes to log via monitor

bugzilla-daemon at bugzilla.mindrot.org bugzilla-daemon at bugzilla.mindrot.org
Tue Feb 21 01:22:52 AEDT 2017


https://bugzilla.mindrot.org/show_bug.cgi?id=2681

            Bug ID: 2681
           Summary: postauth processes to log via monitor
           Product: Portable OpenSSH
           Version: 7.4p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: jjelen at redhat.com

Created attachment 2945
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2945&action=edit
log in postauth via monitor (if there is no /dev/log)

There is a long standing problem with logging in chroots. Especially,
when you use %u in ChrootDirectory, it is nearly impossible to have
/dev/log in every possible chroot for all users.

It seems to be important mainly for sftp-internal session which are
simply configurable to be chrooted and where admins would like to log
sftp session commands.

Similar way as in the pre-authentication phase, we can log the events
in the postauth phase if we know the postauth process will not be able
to open its own /dev/log (generally in chroot).

How does it work?

We are trying to solve this problem on two fronts:
 - In do_child, we check if the /dev/log is available in the chroot and
if not, we "leak the FD" to the internal-sftp process. We also postpone
the closefrom() call after the internal-sftp call.
 - In privsep_postauth(), we have the same check (it could be probably
written more nicely) which takes care of setting up log FDs going
through the monitor.

The idea is that this change should not modify behavior of the existing
setup in case the /dev/log is available in chroot.


Originally posted in on the mailing list over 2 years ago [1] and
discussed in Red Hat bugzilla years ago [2]

I am not sure if there are some other platforms without the /dev/log
concept, but if so, there is still the possibility to make it runtime
option. We are using the attached patch for 2 years in Fedora/RHEL7


[1]
https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-October/033011.html
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1083482#c13

-- 
You are receiving this mail because:
You are watching the assignee of the bug.


More information about the openssh-bugs mailing list