Description of problem:
In the list of world-writeable files, msec reports .hplip/hplib.conf for each user. That is a small security problem that should be fixed
Version-Release number of selected component (if applicable):
always (fully updated Mageia5 Beta1)
Steps to Reproduce:
1. do ls -la $HOME/.hplip
Steps to Reproduce:
home directories should be 755 by default, and by default users get private groups. Hence I don't see the issue, as other users cannot write to that file.
ââââ¼ ls -ald $HOME
drwxr-xr-x 71 user1 user1 4096 Nov 19 23:23 /home/user1/
ââââ¼ ls -al test
-rw-rw-r-- 1 user1 user1 0 Nov 19 23:33 test
ââââ¼ sudo su - user2
[user2@localhost ~]$ echo test >> /home/user1/test
-bash: /home/user1/test: permission denied
Although I still agree this is ugly and should be fixed, and according to Debian should has been fixed by them a long time ago: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=293117
Although I can't seem to find the relevant commit ... :/
In the meantime, I had realised that I was somewhat sloppy in submitting the bug and did not do sufficient testing which would have made me aware of what you point out - sorry.
You are right: the 755 home directory protects a user from having the .hplip/hplip.conf file to be clobbered by another user, even if this is world-writeable. That is not more than ugly, particularly since the problem is on the list of things that will be fixed by debian. I am therefore clsing the bug
(In reply to Juergen Harms from comment #2)
> You are right: the 755 home directory protects a user from having the
> .hplip/hplip.conf file to be clobbered by another user, even if this is
It most certainly does not.
Let's clarify something here. A 755 directory permission will _not_ protect any existing world-writable files from being written to by another user. Not unless another directory in the file path has tighter permissions than that.
The missing write bits for the directory mode only mean that other users may not modify the directory itself by creating or removing files. When it comes to the existing files themselves it's the file permissions that come into play.
Therefore, if the file created by hplip is world-writable (e.g. 666) then a 755 mode on its parent directories will not protect it; that is a security issue that needs to be fixed.
That said, the default umask in Mageia is 022, which creates files that are only writable by their owner. If hplip is ignoring the umask in favor of a more permissive mode, then it should be fixed.
And here comes the actual testing:
- On a fresh Mageia 4.1 install, hplip does *not* create a world-writable file.
- On a M5b1-upgraded-to-Cauldron install ~/.hplip/hplip.conf *is* created as world-writable
- On a Cauldron system upgraded from Mageia 4, if I delete the ~/.hplip/ directory and run e.g. `hp-info; the new ~/.hplip/hplip.conf *is* world-writable.
For reference, the file gets permissions:
hplib creates a world-writeable $HOME/.hplip/hplib.conf file =>
hplib creates a world-writeable $HOME/.hplip/hplip.conf file
hplib creates a world-writeable $HOME/.hplip/hplip.conf file =>
hplip creates a world-writeable $HOME/.hplip/hplip.conf file
(In reply to Juergen Harms from comment #2)
> particularly since the problem
> is on the list of things that will be fixed by debian. I am therefore clsing
> the bug
Maybe you got me wrong - it is ugly, it should not be world-writeable. And it was fixed _long ago_ by Debian, but seems the fix never made it upstream. And it was quite an issue, excerpt from changelog of the linked debian bug:
hplip (0.8.7-3) unstable; urgency=low
* Henrique de Moraes Holschuh:
* SECURITY FIX: create .hplip.conf on user directory mode 600 (was 666)
The HPLIP suite was failing to set the process umask to sane values,
hpssd.py and hpguid.py were affected. Also, modify HPLIP so that it
warns the user of the broken permissions, ignores such a file, and
fixes the permissions on the next time the config file is written to.
Thanks to Erwan David <firstname.lastname@example.org> for reporting this bug
If someone could help me track down the commit for that bug that would be greatly appreciated. Debians gitweb and websvn for the packages seems to be unavailable, and patch-tracker.debian.org has been taken offline due to missing maintainer :/
I can fix the umask issue myself probably, but I'd like to have the complete fix instead of having to redo it for nothing ...
The python code that causes this problem is shown below, to run, save it e.g. as test.py. Shell commands to show the problem follow.
When the .hplip directory already exists, the new hplip.conf gets the correct permissions. This is also demonstrated below.
Could a python expert check what is wrong?
rm -rf ~/hpliptest2
ls -l ~/hpliptest2
-rw-rw-rw- 1 user user 0 Nov 20 20:21 hplip.conf
rm -f ~/hpliptest2/hplip.conf
-rw-r--r-- 1 user user 0 Nov 20 20:25 hplip.conf
homedir = os.path.expanduser('~')
hplipdir = os.path.join(homedir, "hpliptest2")
status = 0
if not os.path.exists(hplipdir):
s = os.stat(homedir)
os.chown(hplipdir, s[stat.ST_UID], s[stat.ST_GID])
status = 1
log.error("Failed to create %s" % hplipdir)
return status, hplipdir
sts, user_dir = getHPLIPDir()
user_config_file = os.path.join(user_dir, 'hplip.conf')
if not os.path.exists(user_config_file):
s = os.stat(os.path.dirname(user_config_file))
os.chown(user_config_file, s[stat.ST_UID], s[stat.ST_GID])
Forgot the second "ls -l ~/hpliptest2" but should be clear enough.
Much feedback on a - precipitately - closed bug. Some summarizing:
Bug report + Comments #4 & #5: .hplip/hplip.conf is created world-writeable ( not so on Mageia 4)
Comments #1 and #6: a corresponding bug report exists on Debian, is probably resolved there, but, so far, no correction on Mageia. Florian is pursuing this issue
Commens #2 abd #3: ashes on my head. I just logged in (on a newly installed Mageia5 Beta 1 box) as user guest and had no difficulty to write junk to ~harms/.hplip/hplip.conf). Hence, this is more than uggly and noise in msec reports, it is a real security issue.
The bug is reopened
(In reply to Juergen Harms from comment #9)
> Bug report + Comments #4 & #5: .hplip/hplip.conf is created world-writeable
> ( not so on Mageia 4)
I can confirm, it works correctly in Mageia 4.
> Comments #1 and #6: a corresponding bug report exists on Debian, is probably
> resolved there, but, so far, no correction on Mageia. Florian is pursuing
> this issue
The debian issue is old and was reportedly fixed upstream. So no this is a *new* problem (although it may very well be a recurrence of the same issue).
I verified this permissions problem in debian jessie ("testing" pre-release") and ubuntu utopic (latest release). So no it is not "fixed" there, it is a new problem and their hplip is still broken.
OK now towards a solution; the cause of this mess is the
in the getHPLIPDir() function. This immediately explains why the permissions are correct if the ~/.hplip directory alrady exists -- getHPLIPDir() is not called in that case so umask is not set to 0.
Now the question is: what is it doing there, can we simply remove this line?
Should be fixed with hplip-3.14.6-7.mga5 .
Is fixed, thanks, closing