bugGNU Octave - Bugs: bug #53515, gui: operate correctly even when...

 
 

bug #53515: gui: operate correctly even when QSettings is non-existent / unreadable / unwritable

Submitted by:  Dan Sebald <sebald>
Submitted on:  Thu 29 Mar 2018 05:19:04 PM UTC  
 
Category:  GUI Severity:  2 - Minor
Priority:  1 - Later Item Group:  Missed Error or Warning
Status:  Postponed Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  dev Operating System:  Any

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)

Thu 29 Mar 2018 07:54:35 PM UTC, comment #6:

Agreed. I really think that we can drop the default-settings file and then can run octave with a non-readable/writable settings file. But this is not really highest priority.

Torsten <ttl>
Project Member
Thu 29 Mar 2018 07:23:11 PM UTC, comment #5:

Yes, that is the main issue. This is a post 4.4 priority. It's important, but too risky to change just prior to a release.

Dan Sebald <sebald>
Thu 29 Mar 2018 07:16:08 PM UTC, comment #4:

> I don't think having a non-writable qt-settings should make Octave inoperable.


I agree with that. I discussed with Torsten on another bug report (bug #52090) about trying to make the GUI less dependent on the default settings being set correctly, use default values declared in a single place in the code, and not break if the settings file is unreadable or can't be created for any reason.

Do you want to make this bug be about that?

Mike Miller <mtmiller>
Project Administrator
Thu 29 Mar 2018 07:02:51 PM UTC, comment #3:

Because Octave is run as root doesn't necessarily mean it has to save a file with root ownership. As an example, here vi doesn't change the ownership of the file:

Yes, if no such file exists, it is different:

I suppose that creating a new qt-settings file with an ownership other than root would be a security risk, but if the file already exists with a certain ownership, why change it?

Nonetheless, I don't think having a non-writable qt-settings should make Octave inoperable. Just when and how qt-settings should be written (i.e., write everytime someone repositions the window layouts so that if Octave crashes, the most recent layout is retained?) could be done better.

Dan Sebald <sebald>
Thu 29 Mar 2018 06:08:54 PM UTC, comment #2:

I have known about this for quite a while, and IMHO I don't see anything that Octave needs to fix. Obviously if someone runs a program as root, and HOME is set to your user's home directory, then some files may be created owned by root.

Ideally, if you actually do run Octave as root, then you would be sure that HOME is set to /root, with 'sudo -H' or 'sudo env HOME=/root octave --gui'.

Mike Miller <mtmiller>
Project Administrator
Thu 29 Mar 2018 05:58:14 PM UTC, comment #1:

This primarily affects Ubuntu and Mint users. Ubuntu has sudo configured to keep the user's HOME directory by default. If you use "sudo -H" you shouldn't have this problem.

Users on other distros would have to use "sudo env HOME=$HOME ..." to emulate the Ubuntu behavior.

Mike Miller <mtmiller>
Project Administrator
Thu 29 Mar 2018 05:19:04 PM UTC, original submission:

I was testing some installation issues (Documentation QHC) and ran Octave using "sudo" to see if the feature would work correctly and where a hidden directory goes to. In the process, I discovered that doing this writes a settings file that is owned by root:

Subsequently, on a follow up non-sudo launch Octave complains

Two things about this are

1) This shouldn't be a critical error, but perhaps put up a warning dialog that settings will be default (can't read) and will not be saved (can't write). However, I know that this is a critical error, because Octave GUI docked-widget/float-window will use the settings file as an intermediate storage area. Hence, Octave GUI can't possibly function. On the other hand, I've recently created a changeset

https://savannah.gnu.org/bugs/?53276

that doesn't use the settings as in intermediate (i.e., save then read), but instead only saves to settings and keeps an internal record of both docked and float positions.

2) There should be special care about writing settings files that are of different ownership than the original settings file. Either don't overwrite, or put up a dialog box at exit (or wherever) warning about the overwrite and whether Octave should do so.

Dan Sebald <sebald>

 

(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 ttl (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by sebald (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 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-03-29 mtmiller Severity3 - Normal => 2 - Minor
        Priority5 - Normal => 1 - Later
        StatusNone => Postponed
        SummaryRunning Octave GUI as "sudo" creates a settings file owned by root => gui: operate correctly even when QSettings is non-existent / unreadable / unwritable

    Back to the top


    Powered by Savane 3.3