>How does that stop them? So they scp it to somewhere under their home>dir,=

then they ssh in and mv it wherever they want. Or they use sftp.
Let's see.... The users that would be given this feature, wouldn't be given=
a password for their login. ie - they are required to use their key.
Their login shell (in /etc/passwd) would be /usr/local/bin/scp -T ./data
Their key would be locked via "command=3D" to running the same scp -T ./dat=
a command

Their authorized_keys file would be read-only. Their .ssh directory would =
be read only.
Their home directory would be read-only. =

There would be a "data" directory under their home directory that is the on=
ly thing writeable.
>As to why, uh, because it's an effective way to do what you want that>does=

n't require modifying scp semantics.
Really? How is it effective if you have to copy libraries to every users' =
home directory structure in order to allow them to use chroot'd code?

chroot cannot be run as anyone but root, so you cannot use it in the "comma=
nd=3D" section (i've tried).

>Ah, so you want to use scp as a shell. Most peculiar. Would that even work=

? Yes - it works very well, except that it doesn't restrict the user to th=
eir home directory.

>It seems to me you want to add constraints to scp's behavior that may be
>difficult to enforce, in order to implement something that is not really
>any of ssh's business. Have you tried WebDAV over SSL?

I want to add a simple parameter parse that errors out if "../" is in the r=
emote path, and adds "./" between the host segment and path segment of the =
remote path.

I'm not asking to *enforce* anything. I'm not asking for tons of changes t=
o watchdog anything. I'm only asking for a very simple front end change th=
at takes effect when scp is started with "-T" instead of "-t".

Simple administrative tasks and permissions will take care of the rest.

It's a very subtle change, one that won't impact anyone who uses scp in it'=
s default manner, and would give admins a very simple and effective tool to=
restrict secure file transfers (ie production system transfers - not day t=
o day users) to the directory we designate as the remote source/destination.

Whether or not you can see the need for something like this, or agree with =
my reasoning for this, I'm asking simply, can it be done? What harm would =
there be in adding it? =




__________________________________________________ _______________
Climb to the top of the charts!=A0 Play Star Shuffle:=A0 the word scramble =
challenge with star power.
openssh-unix-dev mailing list