Koozali.org formerly Contribs.org

Obsolete Releases => SME 7.x Contribs => Topic started by: judgej on November 08, 2006, 06:49:29 PM

Title: "Users Remote Access" chroot location not sticking
Post by: judgej on November 08, 2006, 06:49:29 PM
This is a problem I had with SME6, and am not having with SME7. I seem to remember the solution was something obscure, but I can't remember exactly what it was.

Basically, when entering a custom "chroot location" for a user in the Users Remote Access panel, the custom directory is getting blanked out. I can select a directory from the drop-down list, and that sticks fine, but cannot enter any other directories.

Any clues? Is it working for others, or do I need to raise a bug? Is it related to a different option somewhere else (I have a hunch it is).

-- Jason
Title: How I fixed it
Post by: judgej on November 09, 2006, 03:53:37 PM
I changed this file in FormMagick:

Code: [Select]
/usr/lib/perl5/site_perl/esmith/FormMagick/Panel/remoteuseraccess.pm

On like 270, I replaced this:

Code: [Select]
$ChrootDir = $ChrootDir2 || '';

With this:

Code: [Select]
  if (($ChrootDir eq '' ) and ($ChrootDir2 ne ''))
   {
      $ChrootDir = $ChrootDir2 || '';
   } else {
      $ChrootDir = $ChrootDir || '';
   }


I'm sure it is not completely correct (i.e. it still lacks any validation), but it works okay for my purposes.[/code]
Title: "Users Remote Access" chroot location not sticking
Post by: stephen noble on November 09, 2006, 05:39:07 PM
fixed here
http://bugs.contribs.org/show_bug.cgi?id=2046

jason could you mark as verified if your happy

regards stephen
dungog.net/sme
Title: "Users Remote Access" chroot location not sticking
Post by: judgej on November 10, 2006, 02:59:10 AM
Quote from: "snoble"
fixed here
http://bugs.contribs.org/show_bug.cgi?id=2046

jason could you mark as verified if your happy

regards stephen
dungog.net/sme


Thanks! That was amazingly quick. I'll check out the patch tomorrow when I'm back at the office (with access to the server).

We design and publish various magazines and books, and being able to offer FTP access to advertisers and printers, for transferring Gigabyte PDFs back and forth, is made very easy using this add-on. We have one i-bay for holding the files (easily accessed locally by Macs and PCs using SMB), and sub-directories for each advertiser and printer. They have their own FTP/SFTP logins, and we use the custom paths to set then to the appropriate sub-directory when they connect. We try to avoid creating more i-bays then we need, otherwise the permissions start becoming unmanageable pretty quick (espectially with N users each in their own group, and each with their own i-bay).

Anyway - just a bit of background to give you an idea of how your module/panel is being used.

-- Jason
Title: "Users Remote Access" chroot location not sticking
Post by: judgej on November 11, 2006, 10:50:29 AM
Quote from: "snoble"
fixed here
http://bugs.contribs.org/show_bug.cgi?id=2046

jason could you mark as verified if your happy


Stephen,

The patch fixes the admin of the paths in the panel, but I have a feeling the path restrictions themselves are not working. I've set up several users with custom paths and others with i-bay paths, but when they SFTP in they are always taken to their home directory. But more seriously, they are not restricted to their home directory (they can see all the directory levels, right up to /).

I'm doing a bit more investigation on this, and I'll report back what I find, but it certainly isn't what the SME6.5 version used to do.

-- JJ
Title: "Users Remote Access" chroot location not sticking
Post by: stephen noble on November 11, 2006, 01:47:59 PM
SFTP uses SSH not FTP and this has never restricted users

from the changelog

Description :
SME server enhancement to provide a server-manager panel under security
where you can enable shell access on a user by user basis.

Shells available bash, optionally with sudo
or rssh which allows scp sftp rsync cvs rdist
TODO Chroot RSSH shell access.

and from the panel
"Select an FTP Chroot path"

each user needs their own chroot jail for ssh chroot to work
seems like a lot of work
there may be shortcuts eg to chroot users to their home dir one chroot jail may be able to be shared

would you like to open another bug
so the limitation is spelled out clearer

regards
Title: "Users Remote Access" chroot location not sticking
Post by: judgej on November 11, 2006, 02:09:52 PM
I see. I had always assumed that the FTP and SCP/SFTP logins were restricted in the same way. They are, in fact, completely independent.

I'll do a bit of background reading, and maybe raise a FR (which, as you say, looks like it could be a lot of work, so best gauge the level of interest first).

I could see some of those other shells be very handy for secure file transfer, backups etc. The only shell I can see in the selection box at the moment is /bin/bash

At the moment we are stuck between a rock and a hard place wrt file transfer into the server. We either provide a secure means of file transfer, but we cannot restrict the landing directory that the files go to, or we provide a much less secure means of transfer (FTP) for which there are already dire warnings in the admin screens warning you not to enable it, but at lesat we then get to chose where files go, and can restrict access to that directory.

-- JJ
Title: "Users Remote Access" chroot location not sticking
Post by: stephen noble on November 11, 2006, 02:30:21 PM
>The only shell I can see in the selection box at the moment is /bin/bash

rssh is enabled at RSSH + VPN

yes it isn't clear, but the way the properties were setup make this the least confusing way

>At the moment we are stuck between a rock and a hard place

yes
Title: "Users Remote Access" chroot location not sticking
Post by: judgej on November 11, 2006, 03:35:05 PM
Quote from: "snoble"
>
>At the moment we are stuck between a rock and a hard place

yes


Glad it's not just me misunderstanding the whole thing then. Still, what we have is great, and I very much appreciate it. I'll need to stick with FTP for some clients, and will set up firewall rules at the router to try and protect the server a little.

The new password scheme, enabled by default in SME7, also helps a lot to protect against brut force attacks, as does yum for keeping up-to-date with security patches. Yes, SME gets better and better...

-- JJ