[prev in list] [next in list] [prev in thread] [next in thread]
List: scponly
Subject: Re: [scponly] Further // usage confusion ... possible bug ?
From: Paul Hyder <Paul.Hyder () noaa ! gov>
Date: 2006-03-30 19:22:27
Message-ID: 442C2FF3.6030005 () noaa ! gov
[Download RAW message or body]
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@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...
>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic