Matt,
So in the end, a restricted shell is essentially so crippled as to be
effectively useless, and there exists no actual concrete "definition" of
what, if anything, useful might in reality be accomplished with a
restricted shell.
I should point out that this is quite different from the impression that
was presented earlier in this process, so I'm disappointed in how this
has been presented and handled. It feels to me like a process of decree
where there is no recourse:
"We've come to claim your property to build a new highway; we're very
sorry that you'll have to move out before the end of October, but it is
for the greater good."
Regards,
Ed
On 27.08.2019 16:44, Matthew Ward wrote:
Hi Ed,
The restricted shell was originally created with the goal of
providing committers a way to interact with the downloads/archive
filesystems for releng activities, and version control systems without
providing a general purpose shell. So naturally the command set
available leans in that direction(mv,cp,mkdir,git etc).
We are certainly willing to discuss adding extra commands either
temporarily or permanently, but I want to make it clear that the goal
is not to reproduce bash.
-Matt.
On Mon, Aug 26, 2019 at 9:58 AM Ed Merks <ed.me...@gmail.com
<mailto:ed.me...@gmail.com>> wrote:
What will we be able to do in restricted shell? Using vi is a
very basic activity. I suppose there must be some good reason why
that's restricted? Earlier I was under the impression that such
simple things would continue to work, but now I have to wonder.
But then it was mentioned that things we discover needed could
become unrestricted...
On 26.08.2019 15:35, Matthew Ward wrote:
Hi David,
Thanks for the questions.
Users with the restricted shell will have the same home
directories that they do currently, which will remain the place
for authorized keys. You won't be able to edit(vi/emacs/ed)
files directly within the restricted shell, so you will need to
upload them via scp/rsync. If you want a more 'interactive' type
of access I'd suggest looking into using libfuse, and
specifically the sshfs file system.
The restricted shell allows rsync, so there should be zero
impact. If you'd like to test in advance, drop me a line and
I'll set you up.
-Matt.
On Sat, Aug 24, 2019 at 3:23 PM David Williams
<david_willi...@acm.org <mailto:david_willi...@acm.org>> wrote:
On 8/23/19 14:24, Matthew Ward wrote:
Hi Everyone,
I just wanted to follow up with a reminder that on August
28th we will be moving committers that have an actual shell
on Eclipse.org to our restricted shell.
I'd like to thank both Donat and Etienne on the Buildship
RelEng team who volunteered to test this change, and helped
me confirm that this change should be minimally disruptive.
If you have any questions, please let me know.
-Matt.
Thanks for the reminder.
Will those of use that still want to use 'scp' and similar
still have a 'home directory' (on "build"?) and is that still
the place for .ssh/authorized_keys2? Or, does all that change
with "restricted shell"?
If a change, can you point me to instructions on how to set
that up? I would assume some form of "ssh-copy-id hostname"
but thought best not to assume and ask explicitly.
In case you are wondering, the use case, for using scp and
similar is to download a number of builds to my local machine
(without going through web interfaces).
Now that I think of it, I currently use rsync via ssh, such as
rsync -a -e ssh ${committer_id}@build.eclipse.org:$
<mailto:committer_id...@build.eclipse.org:$>{dlpath}
"${output_dir}"
Will that still work with a restricted shell? Or, will I need
to convert to "scp"?
Thanks,
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
<mailto:cross-project-issues-dev@eclipse.org>
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
<mailto:cross-project-issues-dev@eclipse.org>
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
<mailto:cross-project-issues-dev@eclipse.org>
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
