[scponly] Further // usage confusion ... possible bug ?

[Paul Hyder]

Sounds like chroot behavior confusion.  Your chroot point is
"/usr/home" and the user is logically logged in to the
home directory of "/usr/home//username" which in the chroot
becomes the directory "/username" and is the directory
where the user has write permission.  The chroot "/" is one
level above the username directory and contains things
that have to be in the chroot like etc, bin, lib, {perhaps
multiple username directories}, etc.

You can't (and MUST NOT be able to) write into the chrooted
"/", you want the user's home directory.
   Paul Hyder
   NOAA Earth System Research Laboratory, Global Systems Division
   Boulder, CO

Ensel Sharon wrote:
> 
> On Thu, 30 Mar 2006, Paul Hyder wrote:
> 
> 
>>Ensel Sharon wrote:
>>
>>>...
>>>/usr/home//username
>>>
>>>(where the chroot supporting etc/usr/bin directories for multiple users
>>>are in /usr/home)
>>>
>>>Should allow me to scp like this:
>>>
>>>scp /file username at servername:/
>>>
>>>but it doesn't - I _still_ have to specify the subdirectory on the scp
>>>command line:
>>>...
>>
>>Actually it wouldn't normally permit the scp above; "/" is the chroot
>>point NOT the users directory.  You ABSOLUTELY DO NOT want users to have
>>write permission in "/".
> 
> 
> 
> No, not in _the real_ /, of course not - but the explanation that the
> author gave as to how // works is that you are moved into the subdirectory
> (no longer the real "/").
> 
> Why doesn't // in the home directory cause "/" in the scp line to be what
> is specified after the // ?  If you look at my first post today, in which
> I quote the scponly author, that does seem to be what he is saying it
> does...
>