bugGNU Octave - Bugs: bug #57641, pkg install fails for noexec /tmp

 
 

bug #57641: pkg install fails for noexec /tmp

Submitted by:  Daniel Kraft <domob>
Submitted on:  Mon 20 Jan 2020 11:15:16 AM UTC  
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Feature Request
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  5.1.0 Operating System:  GNU/Linux

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Tue 21 Jan 2020 06:53:07 PM UTC, comment #7: 

If you want pkg to exit with an error message, it should only be in the case when a package build has a configure script. A simple makefile build should be assumed to work.

Mike Miller <mtmiller>
Project Administrator
Tue 21 Jan 2020 12:00:05 PM UTC, comment #6: 

@Daniel;
+1 for a pkg.m patch.
On Windows it's a bit easier as each user there has a scratch directory in the local profile (%HOMEDIR%/Appdata/Local/Temp); so Windows systems can be ignored explicitly when preparing a patch.

I'm not very knowledgeable with Linux system setup, but does Linux have alternative tmp-like locations for scratch files? If global /tmp is noexec (the reasons for which I understand very well) there might be one in the user's home dir.

@Mike:
Bug or not, I think pkg.m can & should do better than just blindly rely on an "exec" scratch dir these days; a point being that for unwary users the cause of the 'pkg install' failure might be hard to track down.
Octave uses /tmp for several other functions but TTBOMK those functions do not execute unpacked files.

Philip Nienhuis <philipnienhuis>
Project Member
Tue 21 Jan 2020 06:20:41 AM UTC, comment #5: 

To be honest, I'm not quite sure what can be done about this.  For one, just having the workaround documented here might help others who run into this and are looking for a fix.

But obviously the ideal situation is one where "pkg install" just works.  Given that this might be infeasible to do, maybe pkg could check if the temporary folder it uses has noexec, and if it does, display a proper error message and tell the user to apply TMPDIR.

I can try to work on a patch for this if you agree that's the best we can do.

Daniel Kraft <domob>
Mon 20 Jan 2020 06:58:56 PM UTC, comment #4: 

Yeah, setting TMPDIR is the best workaround for this.

If you consider this a bug, what kind of a solution do you think would fix this?

Mike Miller <mtmiller>
Project Administrator
Mon 20 Jan 2020 03:58:08 PM UTC, comment #3: 

Ah I see, I tried to set "TMPDIR" with "setenv" inside the Octave session.  But when I start Octave with that setting, I can also manipulate the output of "tempname()".

Mark as confirmed.

Kai Torben Ohlhus <siko1056>
Project Member
Mon 20 Jan 2020 03:49:44 PM UTC, comment #2: 

Actually, it seems to be possible to work around this issue with TMPDIR.  That's what I did in the end.

As I wrote in the OP, I still think this should be considered a "bug" - but it is probably not a very severe one and might be hard / infeasible to fix properly.

Daniel Kraft <domob>
Mon 20 Jan 2020 03:43:02 PM UTC, comment #1: 

Would it be more useful to make the `pkg` temporary directory configurable in this case?  `pkg` has `tempname()` hard coded which unfortunately is not manipulate able like `tempdir()` with the "$TMPDIR" environment variable.

https://hg.savannah.gnu.org/hgweb/octave/file/93f455582f60/scripts/pkg/pkg.m#l403

https://hg.savannah.gnu.org/hgweb/octave/file/93f455582f60/scripts/pkg/private/install.m#l67

https://octave.org/doc/v5.1.0/XREFtempname.html

Kai Torben Ohlhus <siko1056>
Project Member
Mon 20 Jan 2020 11:15:16 AM UTC, original submission:  

If /tmp is mounted noexec (which some people recommend as a security practice), then installing a package with "pkg install" fails.  The reason is that the installation procedure (in particular, configure_make.m) unpacks the package archive into /tmp and then tries to run "./configure".

This issue can easily be fixed by explicitly running the script with a shell (i.e. using "sh ./configure").  However, this still won't let me install the package successfully, because then configure itself complains that it can't run the generated C++ test program (error: cannot run C++ compiled programs).

So I'm not sure how feasible it is to fix this (but it seems like a minor bug / feature request anyway).

Daniel Kraft <domob>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by siko1056 (Posted a comment)
  • -email is unavailable- added by domob (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-01-20 siko1056 StatusNeed Info => Confirmed
    2020-01-20 siko1056 StatusNone => Need Info

    Back to the top


    Powered by Savane 3.5