Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#17743 closed defect (duplicate)

Plots are not shown in the notebook using server_pool option

Reported by: novoselt Owned by:
Priority: blocker Milestone: sage-duplicate/invalid/wontfix
Component: notebook Keywords:
Cc: Merged in:
Authors: Reviewers: Jeroen Demeyer, Volker Braun
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Status badges

Change History (45)

comment:1 Changed 6 years ago by novoselt

In case it helps: I had a similar issue upgrading to Sage-6.4 in SageCell. The solution was https://github.com/novoselt/sage/commit/6b47f2e388a7e7b23243862a314313abe1344ed3

comment:2 Changed 6 years ago by jdemeyer

works for me...

are you using vanilla Sage 6.5.rc0?

comment:3 Changed 6 years ago by jdemeyer

In any case, you should test with #17645.

comment:4 Changed 6 years ago by vbraun

works for me, too.

comment:5 Changed 6 years ago by jdemeyer

  • Milestone changed from sage-6.5 to sage-duplicate/invalid/wontfix
  • Reviewers set to Jeroen Demeyer, Volker Braun
  • Status changed from new to needs_review

comment:6 Changed 6 years ago by jdemeyer

  • Status changed from needs_review to positive_review

comment:7 Changed 6 years ago by vbraun

  • Resolution set to worksforme
  • Status changed from positive_review to closed

comment:8 Changed 6 years ago by novoselt

I have observed it on my installation with a separate worker account. After make distclean and recompiling I still see this, while on a local machine everything works fine.

Can someone test it with multiple accounts?

comment:9 Changed 6 years ago by vbraun

Multiple accounts or server_pool? I tried both and they both work. Do you get any log on the commandline?

comment:10 Changed 6 years ago by novoselt

Yes!

2015-02-08 17:13:19-0700 [HTTPChannel,5,192.168.122.1] Error copying file from worksheet process: [Errno 13] Permission denied: '/tmp/tmpeF7EjV/sage0.png'

This is after executing a command that should show a plot, but does not. The file has 0600 permissions. It seems that commands with explicit show do not create these files, they are served from somewhere else (or perhaps moved?).

comment:11 Changed 6 years ago by jdemeyer

  • Description modified (diff)
  • Milestone changed from sage-duplicate/invalid/wontfix to sage-6.5
  • Summary changed from Plots are not shown in the notebook without show to Plots are not shown in the notebook using `server_pool` option

Confirmed with server_pool!

I think this bug should be reopened as Sage 6.5 blocker.

comment:12 Changed 6 years ago by jdemeyer

  • Summary changed from Plots are not shown in the notebook using `server_pool` option to Plots are not shown in the notebook using server_pool option

comment:13 Changed 6 years ago by vbraun

Thats a configuration issue, the worker process needs to set a umask (in .bashrc, for example) that allows the server to read the temporary files.

comment:14 Changed 6 years ago by jdemeyer

  • Description modified (diff)

It's not purely a configuration issue, as Sage 6.3 does not have this problem.

6.4 and 6.4.1 do have the problem.

Last edited 6 years ago by jdemeyer (previous) (diff)

comment:15 Changed 6 years ago by jdemeyer

  • Description modified (diff)

comment:16 Changed 6 years ago by jdemeyer

  • Description modified (diff)

comment:17 Changed 6 years ago by jdemeyer

  • Description modified (diff)

comment:18 Changed 6 years ago by kcrisman

That seems to be about the time the new display hook was brought into play, maybe?

comment:19 follow-up: Changed 6 years ago by vbraun

There are a number of other permission issues, e.g. by default server_pool doesn't work on my machine because my home directory is 0x700 so the worker can't start my Sage installation.

IMHO its a stupid design to send data back in temp files, the results should be serialized properly and sent though a pipe or socket. See also: Make Sage usable as a library (https://groups.google.com/d/msg/sage-devel/87Rlenvcfrs/-vOyTkZ_FGYJ)

comment:20 in reply to: ↑ 19 ; follow-ups: Changed 6 years ago by jdemeyer

Replying to vbraun:

There are a number of other permission issues, e.g. by default server_pool doesn't work on my machine because my home directory is 0x700 so the worker can't start my Sage installation.

You mean you install Sage in your unaccessible home directory? Now that's a configuration problem, not a Sage issue.

IMHO its a stupid design to send data back in temp files

Perhaps, but that's not the point of this ticket.

comment:21 in reply to: ↑ 20 Changed 6 years ago by novoselt

Perhaps, but that's not the point of this ticket.

Exactly - what we have is a subtle but important regression that appears under certain conditions, which perhaps has a relatively easy fix. "Configuration problem" is when nothing works at all and there are some indications to what is wrong. Here, a fix would be to set group readable permissions somewhere where those files are created, instead of relying on UMASK (or perhaps set/improve UMASK at the start of Sage to be what is necessary). I am also curious why these files are treated differently than those created with explicit show command...

comment:22 in reply to: ↑ 20 ; follow-up: Changed 6 years ago by vbraun

Replying to jdemeyer:

You mean you install Sage in your unaccessible home directory? Now that's a configuration problem, not a Sage issue.

But every new distro defaults to private home directories, and you have to guess from a rather obscure error message that this is the issue.

comment:23 Changed 6 years ago by jdemeyer

  • Description modified (diff)

comment:24 in reply to: ↑ 22 Changed 6 years ago by jdemeyer

Replying to vbraun:

But every new distro defaults to private home directories, and you have to guess from a rather obscure error message that this is the issue.

In any case, that's also not what this ticket is about.

comment:25 Changed 6 years ago by jdemeyer

  • Description modified (diff)

comment:26 Changed 6 years ago by vbraun

  • Description modified (diff)

Also, temporary files should be private, so I tend to see it as an improvement ;-)

I guess its time for yet another place to weaken security for sagenb wrapped in a if EMBEDDED_MODE...

comment:27 Changed 6 years ago by jdemeyer

  • Description modified (diff)

comment:28 Changed 6 years ago by jdemeyer

  • Description modified (diff)

comment:29 Changed 6 years ago by jdemeyer

  • Description modified (diff)

comment:30 Changed 6 years ago by jdemeyer

Volker, could you please reopen the ticket...

comment:31 Changed 6 years ago by jdemeyer

See #17755 for a one-line patch.

comment:32 Changed 6 years ago by vbraun

  • Resolution worksforme deleted
  • Status changed from closed to new

comment:33 Changed 6 years ago by vbraun

  • Milestone changed from sage-6.5 to sage-duplicate/invalid/wontfix

Duplicate?

comment:34 follow-up: Changed 6 years ago by vbraun

Apparently the server_pool feature works by making directories on the sagenb side world-writable, so the worker (or anybody else) can write into them. And I thought making the worker files world-readable would be bad...

comment:35 Changed 6 years ago by jdemeyer

  • Description modified (diff)
  • Status changed from new to needs_review

comment:36 Changed 6 years ago by jdemeyer

  • Status changed from needs_review to positive_review

comment:37 in reply to: ↑ 34 Changed 6 years ago by jdemeyer

Replying to vbraun:

Apparently the server_pool feature works by making directories on the sagenb side world-writable, so the worker (or anybody else) can write into them. And I thought making the worker files world-readable would be bad...

There is some protection possible by creating all temporary directories inside a common temporary directory (set by the SAGENB_TMPDIR environment variable) and setting that directory with 0711 permissions.

comment:38 follow-ups: Changed 6 years ago by vbraun

Sagenb will set SAGENB_TMPDIR to 0777 on startup. Not that I would want to base my safety on the secrecy of a temp dir name anyways...

comment:39 Changed 6 years ago by vbraun

  • Resolution set to duplicate
  • Status changed from positive_review to closed

comment:40 in reply to: ↑ 38 Changed 6 years ago by jdemeyer

Replying to vbraun:

Not that I would want to base my safety on the secrecy of a temp dir name anyways...

I agree, but it should protect against "script kiddies".

comment:41 in reply to: ↑ 38 Changed 6 years ago by jdemeyer

Replying to vbraun:

Sagenb will set SAGENB_TMPDIR to 0777 on startup.

Are you sure? I cannot reproduce this with Sage 6.5.rc1.

comment:42 follow-ups: Changed 6 years ago by vbraun

Agree, doesn't change SAGENB_TMPDIR permissions. Misremembered that. But it does change the DOT_SAGE/sage_notebook.sagenb/home/admin/0/data to 0777, which even has a pretty much predictable name.

comment:43 in reply to: ↑ 42 Changed 6 years ago by jdemeyer

Replying to vbraun:

Agree, doesn't change SAGENB_TMPDIR permissions. Misremembered that. But it does change the DOT_SAGE/sage_notebook.sagenb/home/admin/0/data to 0777, which even has a pretty much predictable name.

On the other hand, the permissions of DOT_SAGE are changed to 0700, so that would even be pointless.

comment:44 in reply to: ↑ 42 Changed 6 years ago by jdemeyer

Replying to vbraun:

But it does change the DOT_SAGE/sage_notebook.sagenb/home/admin/0/data to 0777

In my DOT_SAGE folder, all data directories have permission either 0700 or 0755...

comment:45 Changed 6 years ago by vbraun

The permission of the data directory is changed to 0777 after the first evaluation. Its changed to 0700 if you shut down the notebook server normally.

Note: See TracTickets for help on using tickets.