New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refuse to run as root user #1115

Merged
merged 5 commits into from Feb 22, 2016

Conversation

Projects
None yet
6 participants
@vivi
Contributor

vivi commented Feb 19, 2016

Hi! I'm a undergraduate at UC Berkeley working with Matthias (@Carreau). This is to resolve #1074. Currently, running the notebook as root will cause the program to terminate, but the --allow-root flag isn't working/being recognized and I'm not sure why.

@Carreau

This comment has been minimized.

Show comment
Hide comment
@Carreau

Carreau Feb 19, 2016

Member

Do you want to add a note id docs/sources/changelog.rst ?

Member

Carreau commented Feb 19, 2016

Do you want to add a note id docs/sources/changelog.rst ?

@willingc

This comment has been minimized.

Show comment
Hide comment
@willingc

willingc Feb 19, 2016

Member

@Secant Welcome! Matthias is a wonderful mentor. I'm part of the Jupyter team at Cal Poly.

@Carreau beat me to the help. I did restart Travis (our continuous integration and testing service). It is green.

Member

willingc commented Feb 19, 2016

@Secant Welcome! Matthias is a wonderful mentor. I'm part of the Jupyter team at Cal Poly.

@Carreau beat me to the help. I did restart Travis (our continuous integration and testing service). It is green.

@Carreau

This comment has been minimized.

Show comment
Hide comment
@Carreau

Carreau Feb 19, 2016

Member

It is green.

Yeah, we can try to make a test. Not sure it is worth though.
If we do that, we can monkey patch os.geteuid() to return always Zero. But I'm not sure it's worth testing that.

Member

Carreau commented Feb 19, 2016

It is green.

Yeah, we can try to make a test. Not sure it is worth though.
If we do that, we can monkey patch os.geteuid() to return always Zero. But I'm not sure it's worth testing that.

@willingc

This comment has been minimized.

Show comment
Hide comment
@willingc

willingc Feb 19, 2016

Member

@Carreau No need for tests on this. I was just explaining what Travis was :)

Member

willingc commented Feb 19, 2016

@Carreau No need for tests on this. I was just explaining what Travis was :)

@rgbkrk

This comment has been minimized.

Show comment
Hide comment
@rgbkrk

rgbkrk Feb 20, 2016

Member

Hey this is cool to do.

Does Windows need to be cased off?

Member

rgbkrk commented Feb 20, 2016

Hey this is cool to do.

Does Windows need to be cased off?

@vivi

This comment has been minimized.

Show comment
Hide comment
@vivi

vivi Feb 20, 2016

Contributor

@Carreau
Under what version in the changelog would I add this change? 4.0.10? Or a new one? :bowtie:

Contributor

vivi commented Feb 20, 2016

@Carreau
Under what version in the changelog would I add this change? 4.0.10? Or a new one? :bowtie:

@takluyver

This comment has been minimized.

Show comment
Hide comment
@takluyver

takluyver Feb 20, 2016

Member

Hi @Secant !

  • In the changelog, start a new section called 'Development' for now - we'll rename it when it actually goes into a release.
  • I think @rgbkrk is right, it needs a separate check for Windows. I guess that the geteuid function is simply not there in Windows, so it would throw AttributeError.
Member

takluyver commented Feb 20, 2016

Hi @Secant !

  • In the changelog, start a new section called 'Development' for now - we'll rename it when it actually goes into a release.
  • I think @rgbkrk is right, it needs a separate check for Windows. I guess that the geteuid function is simply not there in Windows, so it would throw AttributeError.
if os.geteuid() == 0:
self.log.critical("Running as root is not recommended. Use --allow-root to bypass.")
self.exit(1)
except AttributeError as e:

This comment has been minimized.

@takluyver

takluyver Feb 20, 2016

Member

I think it's probably OK here, but it's a good idea to put as little code as possible into a try block when you're catching NameError or AttributeError (any error, really, but especially these), because they can hide mistakes.

E.g. imagine if someone changed the logging level, but accidentally spelled it errorr. That's an attribute error - and the code will silently catch it and carry on as if nothing had happened, disabling the check completely.

@takluyver

takluyver Feb 20, 2016

Member

I think it's probably OK here, but it's a good idea to put as little code as possible into a try block when you're catching NameError or AttributeError (any error, really, but especially these), because they can hide mistakes.

E.g. imagine if someone changed the logging level, but accidentally spelled it errorr. That's an attribute error - and the code will silently catch it and carry on as if nothing had happened, disabling the check completely.

@minrk minrk added this to the 5.0 milestone Feb 22, 2016

@minrk

This comment has been minimized.

Show comment
Hide comment
@minrk

minrk Feb 22, 2016

Member

Thanks, @Secant, welcome to the project!

Member

minrk commented Feb 22, 2016

Thanks, @Secant, welcome to the project!

minrk added a commit that referenced this pull request Feb 22, 2016

@minrk minrk merged commit b0fa952 into jupyter:master Feb 22, 2016

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@Carreau

This comment has been minimized.

Show comment
Hide comment
@Carreau

Carreau Feb 22, 2016

Member

Thanks for taking care of this ! Sorry I was mostly offline this Week-end.

Member

Carreau commented Feb 22, 2016

Thanks for taking care of this ! Sorry I was mostly offline this Week-end.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment