Aw: Re: Howto log multiple sftpd instances with their chroot shared via NFS

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

 



Thanks Peter,

I think both the LD_PRELOAD and overlay fs approach are too complicated and hacky for me. Additionally, the user's chroot NFS share is exported by a proprietary NFS storage appliance (Tegile), and I would like to keep that as a simple nfs server, as we experienced already some stramnge behaviour with that appliance in the past, and I am happy it is working now stable finally.

> Gesendet: Dienstag, 28. September 2021 um 20:27 Uhr
> Von: "Peter Stuge" <peter@xxxxxxxx>
> An: openssh-unix-dev@xxxxxxxxxxx
> Cc: "Hildegard Meier" <daku8938@xxxxxx>
> Betreff: Re: Howto log multiple sftpd instances with their chroot shared via NFS
>
> Hallo Hildegard,
>
> thanks for the summary.
>
> Hildegard Meier wrote:
> > ---------------------------------------------------------------
> > AllowGroups sftp-cust
> > Subsystem sftp internal-sftp -f LOCAL5 -l INFO
> > Match Group sftp-cust
> >     ChrootDirectory %h
> >     ForceCommand internal-sftp -u 0002 -f LOCAL5 -l INFO
> >     AllowTcpForwarding no
> > ---------------------------------------------------------------
>
> This is very sensible configuration but it unfortunately makes the
> LD_PRELOAD approach a bit less desirable. It will still work though.
>
>
> > So a solution for the log problem would be, to not use the chroot
> > logging, but to parse the global sftpd log
> ..
> > But I think this is not trivial to make this reliable and robust,
>
> Agreed. If going the log analysis path I would add -e to the
> internal-sftp command line and run sshd with stderr connected to that
> parser, to be able to keep track of events in a sensible way.
> Log rotation would happen only after (or in) the parser.
>
>
> > If we want to try to keep using the available session chroot
> > logging, man (8) sftp-server says:
> >
> > "For logging to work, sftp-server must be able to access /dev/log.  Use of sftp-server in a chroot configuration therefore requires that
> >      syslogd(8) establish a logging socket inside the chroot directory."
> >
> > As Peter has written here
> > https://lists.mindrot.org/pipermail/openssh-unix-dev/2021-September/039669.html
> >
> > as I understand it is hard coded in the system C library that the log
> > devices name is /dev/log, so this cannot be changed (e.g. to log to
> > chrooted /dev/log_hostname1 on hostname1 and chrooted /dev/log_hostname2
> > on hostname2).
>
> Using LD_PRELOAD e.g. with the code I attached to that email allows
> replacing the C library syslog functionality. My attachment does
> indeed log to /dev/log_hostname1 on hostname1 instead of /dev/log.
>
> However because of internal-sftp (which I still prefer over the alternative;
> maintaining an sftp-server binary and possibly libraries in every homedir)
> the entire sshd would have to be run with LD_PRELOAD.
>
> Note that LD_PRELOAD is only neccessary on n-1 servers; the first
> server can still use /dev/log and the full C library syslog() code.
>
> If the second server where LD_PRELOAD is used does not need to
> support anything besides SFTP, or if you can mandate that, then
> it could be okay to run the entire sshd with LD_PRELOAD. Your IT
> security colleagues may well object and they're not wrong; it's not
> much code but still quite a mighty hammer.
>
>
> > > Maybe someone with more Linux/NFS wit could suggest an OS-side solution
> > > for you?
>
> Before going down the LD_PRELOAD path I considered an overlayfs solution.
>
> It would be nice, but the writable (upper) directory can't be NFS
> with overlayfs so it can not work on the SFTP servers.
>
> But using overlayfs can work on the NFS server. There would then be
> one export for each SFTP server, all of them reaching the same
> homedir contents except for different (empty) <homedir>/dev/ subdirs.
>
> This requires maintaining a second homedir structure on the NFS server,
> but that structure only needs to contain a homedir with one empty dev
> subdir under and nothing else, so it may be doable. Homedirs need
> correct permissions and only one of the two directory inodes for the
> homedir itself will be changed by the respective SFTP server, but on
> the plus side it requires only a single overlay mount, nothing per-user
> and no LD_PRELOAD stuff on the SFTP servers.
>
>
> On the NFS server, assuming that /home is where real homedirs exist
> (this gets mounted directly by one SFTP server), that /var/home2 is
> the second homedir structure with only homedirs and an empty dev subdir
> in each, that /var/home2_work is an empty directory on the same filesystem
> as /var/home2 and that /nfs/home2 is the second export mounted by the
> second SFTP server, then set it up like so:
>
> mount -t overlay overlay -olowerdir=/home,upperdir=/var/home2,workdir=/var/home2_work /nfs/home2
>
>
> Then export /home and /nfs/home2 via NFS.
>
> The SFTP server mouting /home will access /home/<user>/dev/log
> (both syslog-ng and internal-sftp) and the SFTP server mouting
> /nfs/home2 will instead access /var/home2/<user>/dev/log but
> everything else within the homedir is to and from /home/<user>.
>
> If this change can be done on the NFS server I think it's what I'd prefer.
>
>
> Kind regards
>
> //Peter
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@xxxxxxxxxxx
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev



[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux