Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mintsources sets incorrect permissions on written files when user has umask set #97

Closed
spookylukey opened this issue Jun 4, 2017 · 9 comments

Comments

@spookylukey
Copy link

I have 'umask 027' set in my profile, to protect my files from being read by other users on the system by default. (This allows me, for example, to have guest use my computer with a guest account while having private files in my own area).

When I run mintsources and choose a different mirror, the files /etc/apt/sources.list.d/official-package-repositories.list get rewritten, and at the same time, the new permissions get set using umask 027:

Before:

ls -lh /etc/apt/sources.list.d/
total 12K
-rw-r--r-- 1 root root 189 May 18 12:08 google-chrome.list
-rw-r--r-- 1 root root 561 Jun 4 15:35 official-package-repositories.list
-rw-r--r-- 1 root root 585 Jun 4 15:35 official-source-repositories.list

After:

ls -lh /etc/apt/sources.list.d/total 12K
-rw-r--r-- 1 root root 189 May 18 12:08 google-chrome.list
-rw-r----- 1 root root 545 May 31 14:55 official-package-repositories.list
-rw-r----- 1 root root 569 May 31 14:55 official-source-repositories.list

The result is that various things that rely on users being able to read these files stop working. In particular, apt-cache search foo reports:

E: Opening /etc/apt/sources.list.d/official-package-repositories.list - ifstream::ifstream (13: Permission denied)
E: The list of sources could not be read.

Also, the Mint Update Manager often reports an error about the APT cache being corrupted.

These errors are fixed by changing the permissions back to what they were.

Expected behaviour:

Either, the new files should be written ignoring the user's umask (this is probably correct behaviour for a tool that runs as root),
Or, the new files should be written with permissions that allow Mint's own package management tools to continue working,
Or, the new files should be written with the same permissions that they were before.

@spookylukey
Copy link
Author

Also reported here - https://bugs.launchpad.net/linuxmint/+bug/1695731 - not sure which is the right place.

@spookylukey
Copy link
Author

I'm guessing this could be affected by different ways of running sudo e.g. see issue #75

@spookylukey
Copy link
Author

spookylukey commented Jun 4, 2017

Further tests suggest a switch to pkexec could fix this:

$ umask 027
$ sudo touch /home/sudo.test                   
$ pkexec touch /home/pkexec.test               
$ ls /home -lh                                 
total 68K
...
-rw-r--r--   1 root root    0 Jun  4 15:55 pkexec.test
-rw-r-----   1 root root    0 Jun  4 15:55 sudo.test

i.e. pkexec ignores the 027 umask, instead using 022 which is the umask for root I think, while sudo uses the users umask.

@xenopeek
Copy link

Retesting on Linux Mint 18.3 shows mintsources uses pkexec and user's umask is not used for writing to /etc.

@StuartJMackintosh
Copy link

Worth noting that the quick resolution to this issue is to set a+r on the repo file (using Mint 18.3 (XFCE)).

Running this command:
sudo chmod a+r /etc/apt/sources.list.d/official-package-repositories.list

Resolves this issue:

E: Opening /etc/apt/sources.list.d/official-package-repositories.list - ifstream::ifstream (13: Permission denied)
E: The list of sources could not be read.

This is reported in mintupdate as a corrupt apt cache file and prompts to switch mirrors.

@DJCrashdummy
Copy link

DJCrashdummy commented Nov 4, 2018

@xenopeek why was this issue closed?

as you can see at linuxmint/mintupdate#363 (comment) i'm pretty sure there still a permission-bug present.

isn't it possible to add a chmod o+r or chmod a+r to make sure that all modified sources are accessible for mintupdate?

@xenopeek
Copy link

xenopeek commented Nov 5, 2018

I already noted why I closed this issue. I can't reproduce it with the steps you shared; the cause of your issue must be something you haven't identified yet through troubleshooting.

Retested on Linux Mint 18.3 Cinnamon and 19 Cinnamon. Set umask 027 through /etc/profile and ~/.profile, rebooted and confirmed umask in runtime was set to 027 before commencing testing. File /etc/apt/sources.list.d/official-package-repositories.list had permission 0644. I did the following:

  • Started Software Sources through menu as per normal
  • Authenticated on the polkit dialog with my password
  • Selected a different Main and Base mirror
  • Refreshed cache
  • Under Maintenance tab ran Fix MergeList problems and Purge residual configuration
  • Refreshed cache

Afterwards the file /etc/apt/sources.list.d/official-package-repositories.list still has permission 0644.

I also manually set permissions of /etc/apt/sources.list.d/official-package-repositories.list to 0640 but upon selecting a new mirror in mintsources the permissions are reset to 0644.

Thus the cause of your issue must be found in some other action you performed. At least I can't reproduce it. You can ask for help on the forums with troubleshooting, to find the steps to reproduce your issue.

@DJCrashdummy
Copy link

ok, now we've got the point! 😉

sorry for not being 100% specific:
in my case i changed UMASK in the /etc/login.defs to 027, because in the profile i would have to change it for every created user separately, which wouldn't make much sense for a dynamic multiuser-system.

but you are right @xenopeek, @spookylukey talked about setting umask to 027 in his profile... so i'm not sure what his issue is. 😕


should we create a separate issue for UMASK-settings in /etc/login.defs or do we cover the whole umask-topic with this issue?

@spookylukey
Copy link
Author

@spookylukey @DJCrashdummy I think my issue was fixed by the switch to pkexec a while back. I guess opening a new issue would be best, since the original issue is fixed AFAICS.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants