On 20/05/14 Damien Miller wrote:
On Mon, 19 May 2014, ?ngel Gonz?lez wrote:
If you want something different, like chrooting them at /chrooted-users/foo,
you can use -d parameter in the ForceCommand, ie.
ForceCommand internal-sftp -d /%u
If you're willing to live with a single chroot directory and file
permissions to keep users from each others' files then this is a great
solution. It only requires a single /chrooted-users/dev/log listener
too.
-d
He had stated it was acceptable ;)
Nico Kadel wrote:
The necessity for additional arcanery, of having non-user owned
contents inside each working chrooted directory, and this kind of
'make one chroot, but rely on the users to correctly set permissions
and block access to each other's content, even though they can see
each other's directories by default" is exactly why the sftp chroot
setup is not ideal.
Remember they don'r need +r on /home but just +x. They can still confirm
if a user exists, but puts the bar slightly higher. It isn't so extravagant
to require properly set permissions on your folder (I think that by using
posix acls you could forbid them to change the default)
But yes, it's not ideal, which leads to:
Damien Miller wrote:
The syslog problem doesn't have a good solution right now. Maybe someone
could write a patch to implement logging via the monitor, like what happens
for the pre-auth process.
+1
Or it may be easier to leave open an fd to /dev/log.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
