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

[Hildegard Meier]

Thanks Douglas,

did not know abount "mount move" before, interesting.

But unfortunateley, it would be an impractical complicated mess to have this hundrets of extra mounts, which additionally are server specific, so at least for me this would not be a possible approach.

Additionally, reading the mount man page I doubt this would be possible, anyway. I guess /dev/log would not be available in the chroot anymore.
And it says "moving a mount residing under a shared mount is invalid and unsupported".
But as said, this is approach is impractical for me anyways.

"The move operation
       Move a mounted tree to another place (atomically).  The call is:

              mount --move olddir newdir

       This will cause the contents which previously appeared under olddir to now be accessible under newdir.  The physical location of  the  files
       is not changed.  Note that olddir has to be a mountpoint.

       Note  also  that moving a mount residing under a shared mount is invalid and unsupported.  Use findmnt -o TARGET,PROPAGATION to see the cur‐
       rent propagation flags."


> Gesendet: Mittwoch, 29. September 2021 um 15:34 Uhr
> Von: "Douglas E Engert" <deengert at gmail.com>
> An: openssh-unix-dev at mindrot.org
> Betreff: Re: Howto log multiple sftpd instances with their chroot shared via NFS
>
> Thanks for the info on the single NFS volume mount.
> 
> Another take on the direct bind mount:
> 
> 
> If server1 did:
> source s_chroot_<username> { unix-stream("/var/data/chroot/<username>/dev/log_server1" optional(yes) ); };
> 
> Then for each user server1 would also do (or have in fstab):
> mount -bind /var/data/chroot/<username>/dev/log /var/data/chroot/<username>/dev/log_server1
> 
> and server2 did:
> source s_chroot_<username> { unix-stream("/var/data/chroot/<username>/dev/log_server1" optional(yes) ); };
> and also do this:
> mount -move /var/data/chroot/<username>/dev/log /var/data/chroot/<username>/dev/log_server2
> 
> This would allow each server to have its own /dev/log_host so they would not overwrite each others,
> but when the libc went to write to the chrooted  /dev/log, the kernel would write to /dev/log_serverX because
> the direct bind is in the host's kernel.
> 
> 
> 
> I have not tried this.
> 
> 
> 
> On 9/29/2021 3:42 AM, Hildegard Meier wrote:
> > Hi, I tried now the following:
> > 
> > Add the following line to /etc/fstab:
> > 
> > /var/data/chroot                            /usr/local/sftp_chroot_bind_mount   none    bind                0       2
> > 
> > Then:
> > mkdir /usr/local/sftp_chroot_bind_mount
> > mount /usr/local/sftp_chroot_bind_mount
> > 
> > to bind-mount the users's chroot home to /usr/local/sftp_chroot_bind_mount
> > 
> > Then replace in the syslog-ng config:
> > 
> > source s_chroot_<username>    { unix-stream("/var/data/chroot/<username>/dev/log" optional(yes) ); };
> > with
> > source s_chroot_<username>    { unix-stream("/usr/local/sftp_chroot_bind_mount/<username>/dev/log" optional(yes) ); };
> > 
> > Restart syslog-ng
> > 
> > That would have been such a simple workaround.
> > But unfortunately, the problem is not solved with this.
> > The problem is the same, that there is sftp logging only on the sftp server where syslog-ng was restarted least.
> > _______________________________________________
> > openssh-unix-dev mailing list
> > openssh-unix-dev at mindrot.org
> > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> > .
> > 
> 
> -- 
> 
>   Douglas E. Engert  <DEEngert at gmail.com>
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>