Opened 9 years ago
Last modified 5 days ago
#11755 positive_review defect
Allow running Sage.app by someone other than it was installed by
Reported by: | iandrus | Owned by: | iandrus |
---|---|---|---|
Priority: | major | Milestone: | sage-duplicate/invalid/wontfix |
Component: | relocation | Keywords: | mac app SAGE_ROOT |
Cc: | kcrisman, dimpase | Merged in: | |
Authors: | Reviewers: | ||
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | #31270 | Stopgaps: |
Description (last modified by )
Since Sage.app checks if it moved every time upon startup, any user who runs the application needs to be able to write to local/lib/sage-current-location.txt
. This files seems to default to 0644 permissions.
We can either change the Sage.app code so that it doesn't need to check every time or make the file world writable.
Relevant comments from #5852:
jdemeyer said:
I also noticed that
data/extcode/sage/ext/mac-app/start-sage.sh
has its ownSAGE_ROOT
-detecting code but it probably shouldn't and should usesage-env
instead.
leif said:
It seems the MacOS X app wants just the opposite, i.e. to not resolve symbolic links, since the absolute, canonicalized path may frequently change.
Therefore it always creates (on start-up) the same, "constant" symbolic link from
/tmp/sage-mac-app
to the current, volatile$SAGE_ROOT
, which can only work if the application is also actually always built in (a real directory)/tmp/sage-mac-app/
(such that no change of hardcoded paths is necessary).
Change History (11)
comment:1 follow-up: ↓ 3 Changed 9 years ago by
comment:2 Changed 9 years ago by
- Cc kcrisman added
comment:3 in reply to: ↑ 1 Changed 9 years ago by
Replying to leif:
It's not immediately clear to me why an ordinary user would have to move Sage though, just to run the application. (But I don't use apples.)
If an ordinary user moves Sage, then presumably they have write permissions to the new SAGE_ROOT/local/lib, so there won't be any problems, will there?
This all happens in the script sage-location
, right? If Sage detects that its location has moved, then it tries to update various library and pkg-config files. If the user doesn't have permission to do this, then we could just print a warning ("Have your sysadmin do ..." and/or "Try copying the Sage installation to ...") and either bail out or keep going and hope for the best.
In fact, I posted a patch doing some of this (it doesn't print the warning) at #5155. Perhaps we should try to fix this issue here and deal with the other issues from #5155 there.
comment:4 Changed 9 years ago by
- Component changed from user interface to relocation
- Description modified (diff)
- Keywords SAGE_ROOT added
comment:5 Changed 7 years ago by
- Milestone changed from sage-5.11 to sage-5.12
comment:6 Changed 7 years ago by
- Milestone changed from sage-6.1 to sage-6.2
comment:7 Changed 7 years ago by
- Milestone changed from sage-6.2 to sage-6.3
comment:8 Changed 6 years ago by
- Milestone changed from sage-6.3 to sage-6.4
comment:9 Changed 6 days ago by
- Cc dimpase added
- Dependencies set to #21783
- Milestone changed from sage-6.4 to sage-duplicate/invalid/wontfix
- Status changed from new to needs_review
Outdated, should be closed
comment:10 Changed 6 days ago by
- Dependencies changed from #21783 to #31270
That's a matter of the current umask, but we could of course change the file permission on updates to that file. On the other hand, opening an existing file for writing shouldn't change the permissions in the first place. If the file gets deleted inbetween, an ordinary user would also need write permissions on the directory the file is located / recreated in, i.e.
$SAGE_ROOT/local/lib/
.It's not immediately clear to me why an ordinary user would have to move Sage though, just to run the application. (But I don't use apples.)
Allowing the group to write to this file would certainly be better, putting potential users (that move the installation) into that group. (But they still won't be able to actually modify / fix hardcoded paths, which is the whole purpose of
sage-current-location.txt
, so the installation might actually break if it really moved. A better detection in the code that attempts to update that file is another alternative.)The whole issue might be related to #5852 (and previously #11707), such that after this ticket is resolved, changing the permissions may no longer be necessary.