Denis,
Comments below.
On 27.08.2019 19:27, Denis Roy wrote:
Ed,
I think we're one of the last shops on earth that has SSH shell
access right into our mission-critical infra.
Being able to use vi in my home folder doesn't strike me as
treading into your mission-critical infrastructure, but hey, I'm
clearly not well-informed. I must point out though that like
Markus, I provide numerous services that are also mission
critical. But, for the greater good of ultra-security, of course
I'll quickly set aside my summer and my personal life to address,
at my own expense, this latest pressing security concern inorder
to find alternative ways to make things work nevertheless.
But wait, I couldn't do a build for days because Mac signing
didn't work. Oh, and suddenly today, out of nowhere:
[ERROR] The following artifacts could not be downloaded:
[ERROR] osgi.bundle,org.bouncycastle.bcprov,1.61.0.v20190602-1335
[ERROR] Internal error: java.lang.RuntimeException: Some required artifacts could not be downloaded. See log output for details. -> [Help 1]
My builds fail again for another reason. In the end though, ulta-security waits for no person.
Even before 2009 this practice was pure insanity from a
data/systems security perspective but it was maintained as there
were not many options.
Really? File access permissions are so insanely insecure? So if I
login and delete a file, that's just insane, but when I run my
Jenkins job to delete that file, it's totally secure and the world
is safe. I totally don't get it, but as I said, I'm ill-informed.
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 assumed, it's all for the greater good. Much like that "It's
so reassuring that so many people will benefit from that new
highway that will consume your home and property." On that front,
I know I always feel so much more secure when I have to agree to
yet another cookie prompt on a web page. Thanks EU, I feel like
my web experience is totally ultra-cookike-secure now. I just
need that highly in-demand the-make-the-cookie-go-away app. And
whenever I do anything around here where I live now, I have to
sign the data security form, that I can't read, but must sign
nevertheless. It totally makes me feel like my best interests
(security) are always the prime concern.
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.
Of course we were given ample opportunity for justification. And of
course trying to justify insanity would just be proof of insanity.
So good for us that there are those who decree that plain insanity
is something to which we must put and end, immediately, during the
summer, when of course no one has anything better to do than migrate
to the new improved ultra-secure non-insane better alternatives: run
Jenkins jobs for hours trying to do accomplish what you could do in
minutes with a shell.
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.
It's feels so much better to be pissed of unintentionally. :-P
Of course your role is to serve the best interests of the
community, and I feel bad to rag on you because I do feel you are
doing your best to serve the interests of the community. But it
also feels like dogma to me, much like the cookie-phobic,
ultra-data security madness that plagues me at home.
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.
Feel free to open problem reports that we can promptly do nothing
about. No, expect nothing and you will not be disappointed. I will
try to make due without.
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
_______________________________________________
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
|