Should Sage fiddle with .sage file permissions?

[Marc Mezzarobba]

Hi,

I just noticed that Sage unconditionally changes the permissions of the
DOT_SAGE directory to rwx--- even after the user manually modified them
(sage/misc/misc.py, l. 92ff). It seems to me however that there are
perfectly valid reasons to share one's .sage with other users. Worse,
Sage crashes if the attempt to set the permissions fails (try chattr +i
~/.sage).

Despite some comments in the code, I don't understand how people got to
the idea of fiddling with these permissions in the first place, so I'm
not sure how to fix the issue. Any opinions?

Thanks,

--
Marc

[Michael Orlitzky]

On 1/27/20 9:34 AM, Marc Mezzarobba wrote:
> Should Sage fiddle with .sage file permissions?
No. Automating chown/chmod is usually exploitable, but also just no.

[Dima Pasechnik]

I suppose the idea of closing ~/.sage/ to the world was that it may
contain something like (salted or not?) passwods for sagenb,
as well as sagenb notebooks, so that students on the same host don't
have a way to peek at each other homework, etc.

I suppose we can remove these permission changes.



>
> Thanks,
>
> --
> Marc
>
> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/r0msdo%2413j1%241%40ciao.gmane.io.

[Nils Bruin]

On Monday, January 27, 2020 at 7:58:27 AM UTC-8, Dima Pasechnik wrote:

I suppose the idea of closing ~/.sage/ to the world was that it may
contain something like (salted or not?) passwods for sagenb,
as well as sagenb notebooks, so that students on the same host don't
have a way to peek at each other homework, etc.

Indeed. If someone wants to be careful about it, sage might refuse to use or save information there it considers sensitive. Ssh does something similar when it's not satisfied with the permissions of the configuration directory. You'd have to decide if group readable is vulnerable, though.

[Matthias Koeppe]

On Monday, January 27, 2020 at 9:34:41 AM UTC-5, Marc Mezzarobba wrote:

I just noticed that Sage unconditionally changes the permissions of the
DOT_SAGE directory to rwx--- even after the user manually modified them
(sage/misc/misc.py, l. 92ff). It seems to me however that there are
perfectly valid reasons to share one's .sage with other users. Worse,
Sage crashes if the attempt to set the permissions fails (try chattr +i
~/.sage).

  

In my opinion, it should set these permissions when it creates the DOT_SAGE directory

for the first time (similar to how permissions of files like ~/.python_history or ~/.bash_history are set), but not adjust them if the directory already exists. It would be appropriate to write out a warning though if they are more permissive than rwx------.

Matthias

[John H Palmieri]

As noted in the cited part of misc.py, people might also have concerns about their Sage command history. I like the warning idea. It would make more sense to me to have a function which checks whether DOT_SAGE exists, creates it and sets permissions if it doesn't, checks permissions and prints a warning if it exists with bad permissions, is silent otherwise. Then run this function when Sage starts up. That seems better than having code executed at the top-level of misc.py.

--

John

[Jan Groenewald]

Hi

Yes, though our students who start sage by clicking an icon, will never read the warning in the terminal. Would be nice if the warning showed in Jupyter as well.

Or maybe keep fixing the permissions unless an enviroment variable is set, e..g SAGE_ALLOW_INSECURE_DOTSAGE.

Regards,

Jan

--

  .~.
  /V\     Jan Groenewald
 /( )\    www.aims.ac.za
 ^^-^^ 

[Michael Orlitzky]

On 1/27/20 12:59 PM, Matthias Koeppe wrote:
>   
> In my opinion, it should set these permissions when it creates the
> DOT_SAGE directory
> for the first time (similar to how permissions of files like
> ~/.python_history or ~/.bash_history are set), but not adjust them if
> the directory already exists. It would be appropriate to write out a
> warning though if they are more permissive than rwx------.
>

This is the right way to do it. The user/system already has UMASK set to
something generally acceptable. When you create a sensitive file, you
mask more permission bits, create the file, and then revert the umask.
After that, you leave everything alone.

If there are any sensitive plain-text credentials created by Sage and
stored under ~/.sage, then a warning for those would be OK, but
otherwise a warning about something the user did on purpose is
just going to get on everyone's nerves.

[Marc Mezzarobba]

Michael Orlitzky wrote:
> This is the right way to do it. The user/system already has UMASK set
> to something generally acceptable. When you create a sensitive file,
> you mask more permission bits, create the file, and then revert the
> umask. After that, you leave everything alone.

Ok, thank you all for your comments. I implemented a minimal fix at
#29093. People who'd like to see a warning issued in some circumstances
or whatever are welcome to take over the ticket and make the
improvements they find useful :-)

--
Marc