Skip to content
This repository was archived by the owner on Apr 15, 2022. It is now read-only.

Bug with permissions on current working directory when starting sage #12

Open
embray opened this issue Dec 8, 2016 · 2 comments
Open
Assignees

Comments

@embray
Copy link
Owner

embray commented Dec 8, 2016

Some users reported that when they start sage from the SageMath shortcut they get as the first output:

sys:1: RuntimeWarning: not adding directory '' to sys.path since it's writable by an untrusted group.
Untrusted users could put files in this directory which might then be imported by your Python code. As a general precaution from similar exploits, you should not execute Python code from this directory

This is something sage's Python is known to do, but the question is why it's doing it in this case. The directory that sage is installed into should have permissions such that it's not "writable by an untrusted group", but how Cygwin is interpreting the user's ACL could in some cases be incorrect in such a way that causes this warning, but I haven't figured out a way to reproduce yet.

@embray embray self-assigned this Dec 8, 2016
@embray
Copy link
Owner Author

embray commented Dec 13, 2016

I was able to reproduce this, this time. This seems to be related to the fact that we mount C:\Users\<username> as the user's home directory, and start sage there as the current working directory.

However, the group ownership of the directory might not line up with what Sage's Python is expecting here (for example, it may be owned by the SYSTEM user). This is similar to the issue described here: https://cygwin.com/faq/faq.html#faq.using.ssh-pubkey-stops-working

I'm not sure yet how to work around it, but it would be good to fix as this is an alarming warning for an unwary user to see.

@embray
Copy link
Owner Author

embray commented Dec 13, 2016

I've worked around this for now by simply ignoring the warning by setting the following in /etc/profile.d/sagerc.sh:

export PYTHONWARNINGS="ignore:not adding directory '' to sys.path"

It's not ideal though, so I'll leave the issue open while searching for a more solid solution.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant