Ed,
I think we're one of the last shops on earth that has SSH shell
access right into our mission-critical infra. Even before 2009
this practice was pure insanity from a data/systems security
perspective but it was maintained as there were not many options.
With Jenkins per Project (JIPP), there's just no reason to leave
a well-known security faux-pas enabled. It's like putting a credit
card number on LinkedIn.
As I understand it, there were less than 30 people with full
shell access. If hundreds of projects don't need it, it's really
hard to justify.
In the end, we're not here to intentionally piss folks off with
useless dogma -- we're here to help. Part of that mission
statement is making sure our systems don't suffer a catastrophic
compromise/data breach.
Perhaps if we better understand what you use the shell for, we
can help craft CI jobs which will both a) accomplish the task and
b) provide everyone with more visibility into what's going on, as
opposed to some cryptic cron job. Feel free to file bugs in
Community / Jenkins for the tasks you need assistance with.
Denis
On 2019-08-27 12:46 p.m., Ed Merks
wrote:
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.
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
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:${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@xxxxxxxxxxx
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@xxxxxxxxxxx
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@xxxxxxxxxxx
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@xxxxxxxxxxx
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@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
|