[opensuse-factory] Installing mlocate does not create locate group after first time installation
Hello List Mates,
When I selected "mlocate" as one of the packages to install for the first time installation of openSUSE 13.2 RC1, it did not create a "locate" gid group.
However, this worked with openSUSE 13.1. Has any one else noticed this?
Dne Čt 23. října 2014 17:59:08, Roman Bysh napsal(a):
Hello List Mates,
When I selected "mlocate" as one of the packages to install for the first time installation of openSUSE 13.2 RC1, it did not create a "locate" gid group.
However, this worked with openSUSE 13.1. Has any one else noticed this?
Hi
locate group is not necessary with recent mlocate, mlocate is currently executed as nobody.
Also it is usually better to file in bugreport than to ask at mailing list.
Kind regards
Martin
On 10/24/2014 05:05 AM, Martin Pluskal wrote:
Dne Čt 23. října 2014 17:59:08, Roman Bysh napsal(a):
Hello List Mates,
When I selected "mlocate" as one of the packages to install for the first time installation of openSUSE 13.2 RC1, it did not create a "locate" gid group.
However, this worked with openSUSE 13.1. Has any one else noticed this?
Hi
locate group is not necessary with recent mlocate, mlocate is currently executed as nobody.
Also it is usually better to file in bugreport than to ask at mailing list.
Kind regards
Martin
Thanks Martin.
A bug report is being submitted. However, the information that you have provided are not reflected in the description notes.
They still tell the user must be member of "locate". Hence the question on the mail list.
Martin Pluskal wrote:
locate group is not necessary with recent mlocate, mlocate is currently executed as nobody.
---- The requirement for group locate came from the database being owned by group locate, so anyone accessing it had to be in that group.
In order to restrict locate-access only to those files that a user could normally see (and allow files in restricted-permission directories to remain "hidden" from users that wouldn't normally be able to see them).
If the database is only accessible by group nobody, does that users need to be part of group nobody to access it?
Wouldn't it also be giving access to those processes already running in group nobody?
Also it is usually better to file in bugreport than to ask at mailing list.
---- Depends on whether or not it is a bug. If it was deliberately changed, then filing a bug will only get it "rejected" as no longer supported and no one except the package maintainer would be aware of the problem. Vs. documenting that anyone in group nobody might be able to access the results of 'find' run as root is something that should be widely known so security policies can be updated. (For end users that have a security policy).
One of those policies on a secure machine is to NOT lump unrelated processes into the same group or username (ex. 'nobody').
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2014-10-26 18:59, Linda Walsh wrote:
Martin Pluskal wrote:
locate group is not necessary with recent mlocate, mlocate is currently executed as nobody.
---- The requirement for group locate came from the database being owned by group locate, so anyone accessing it had to be in that group.
Notice that mlocate is different from locate:
Telcontar:~ # l /var/lib/mlocate/mlocate.db - -rw-r--r-- 1 root root 54014689 Oct 25 22:20 /var/lib/mlocate/mlocate.db Telcontar:~ #
It is owned by root. And it works:
Telcontar:~ # su - nobody nobody@Telcontar:~> locate mlocate.db /usr/share/man/man5/mlocate.db.5.gz /var/lib/mlocate/mlocate.db /var/lib/mlocate/mlocate.db.VXAzte nobody@Telcontar:~> logout Telcontar:~ #
You do not need to belong to that group, the instructions are plain wrong:
Telcontar:~ # rpm -qi mlocate ... User must be member of locate group in order to use this package. Distribution: openSUSE 13.1 Telcontar:~ #
What you comment applies to locate, not to mlocate.
However, the permission control of mlocate might be broken:
nobody@Telcontar:~> locate 20071006.0109 /home/cer/pine-crash.20071006.0109 /home_aux/cer/pine-crash.20071006.0109 nobody@Telcontar:~> l /home/cer/pine-crash.20071006.0109 ls: cannot access /home/cer/pine-crash.20071006.0109: Permission denied nobody@Telcontar:~> l /home/cer ls: cannot open directory /home/cer: Permission denied nobody@Telcontar:~>
mlocate should not be able to locate a file to which the user running it has no access permission. This is not what was reported on the release notes when the distribution switched from locate to mlocate.
- -- Cheers / Saludos,
Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 10/26/2014 02:55 PM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2014-10-26 18:59, Linda Walsh wrote:
Martin Pluskal wrote:
locate group is not necessary with recent mlocate, mlocate is currently executed as nobody.
---- The requirement for group locate came from the database being owned by group locate, so anyone accessing it had to be in that group.
Notice that mlocate is different from locate:
Telcontar:~ # l /var/lib/mlocate/mlocate.db
- -rw-r--r-- 1 root root 54014689 Oct 25 22:20 /var/lib/mlocate/mlocate.db
Telcontar:~ #
It is owned by root. And it works:
Telcontar:~ # su - nobody nobody@Telcontar:~> locate mlocate.db /usr/share/man/man5/mlocate.db.5.gz /var/lib/mlocate/mlocate.db /var/lib/mlocate/mlocate.db.VXAzte nobody@Telcontar:~> logout Telcontar:~ #
You do not need to belong to that group, the instructions are plain wrong:
Telcontar:~ # rpm -qi mlocate ... User must be member of locate group in order to use this package. Distribution: openSUSE 13.1 Telcontar:~ #
What you comment applies to locate, not to mlocate.
However, the permission control of mlocate might be broken:
nobody@Telcontar:~> locate 20071006.0109 /home/cer/pine-crash.20071006.0109 /home_aux/cer/pine-crash.20071006.0109 nobody@Telcontar:~> l /home/cer/pine-crash.20071006.0109 ls: cannot access /home/cer/pine-crash.20071006.0109: Permission denied nobody@Telcontar:~> l /home/cer ls: cannot open directory /home/cer: Permission denied nobody@Telcontar:~>
mlocate should not be able to locate a file to which the user running it has no access permission. This is not what was reported on the release notes when the distribution switched from locate to mlocate.
Cheers / Saludos,
Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux)
iEYEARECAAYFAlRNQ64ACgkQtTMYHG2NR9XSsQCfTbwBM5oC+QaqfsIxts23rVcP nM4AoI3EsJ/eQFBVyol0LVGkQrbw7MHA =boYz -----END PGP SIGNATURE-----
I've already submitted a bug report: http://bugzilla.opensuse.org/show_bug.cgi?id=902588
However, in response to your comment about permission control being broken, you must submit a bug report asap so it can be fixed in time for 13.2.
Cheers!
Roman
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2014-10-26 23:12, Roman Bysh wrote:
On 10/26/2014 02:55 PM, Carlos E. R. wrote:
I've already submitted a bug report: http://bugzilla.opensuse.org/show_bug.cgi?id=902588
However, in response to your comment about permission control being broken, you must submit a bug report asap so it can be fixed in time for 13.2.
Unfortunately, I have not been able to install factory yet. In 13.1 it needs a change in "/etc/cron.daily/mlocate.cron":
# /usr/bin/su "${RUN_UPDATEDB_AS}" -c "/usr/bin/updatedb ${NODEVS} ${UPDATEDB_PRUNEFS} ${UPDATEDB_PRUNEPATHS}" /usr/bin/su "${RUN_UPDATEDB_AS}" -c "/usr/bin/updatedb --require-visibility yes ${NODEVS} ${UPDATEDB_PRUNEFS} ${UPDATEDB_PRUNEPATHS}"
Thus I can only report against 13.1.
- -- Cheers / Saludos,
Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2014-10-26 23:56, Carlos E. R. wrote:
On 2014-10-26 23:12, Roman Bysh wrote:
On 10/26/2014 02:55 PM, Carlos E. R. wrote:
I've already submitted a bug report: http://bugzilla.opensuse.org/show_bug.cgi?id=902588
However, in response to your comment about permission control being broken, you must submit a bug report asap so it can be fixed in time for 13.2.
Unfortunately, I have not been able to install factory yet. In 13.1 it needs a change in "/etc/cron.daily/mlocate.cron":
# /usr/bin/su "${RUN_UPDATEDB_AS}" -c "/usr/bin/updatedb ${NODEVS} ${UPDATEDB_PRUNEFS} ${UPDATEDB_PRUNEPATHS}" /usr/bin/su "${RUN_UPDATEDB_AS}" -c "/usr/bin/updatedb --require-visibility yes ${NODEVS} ${UPDATEDB_PRUNEFS} ${UPDATEDB_PRUNEPATHS}"
Thus I can only report against 13.1.
Done. Bug 902655
IMHO, it appears that users must be indeed be added to the locate group for permission control to work.
- -- Cheers / Saludos,
Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2014-10-27 00:27, Carlos E. R. wrote:
IMHO, it appears that users must be indeed be added to the locate group for permission control to work.
Clarification:
A user must be added to the locate group in order to call the locate process, and then he gets results only for the files he has access to, not others. Like not being able to get a listing of other people files.
This requires using "--require-visibility yes" in "/etc/cron.daily/mlocate.cron".
And something still remains broken in my system which I have not yet "located".
- -- Cheers / Saludos,
Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
And something still remains broken in my system which I have not yet "located".
Notice that mlocate is different from locate:
Telcontar:~ # l /var/lib/mlocate/mlocate.db
- -rw-r--r-- 1 root root 54014689 Oct 25 22:20 /var/lib/mlocate/mlocate.db
Telcontar:~ #
It is owned by root. And it works:
Telcontar:~ # su - nobody nobody@Telcontar:~> locate mlocate.db /usr/share/man/man5/mlocate.db.5.gz /var/lib/mlocate/mlocate.db /var/lib/mlocate/mlocate.db.VXAzte nobody@Telcontar:~> logout Telcontar:~ #
--- How can you say it works AND that something is broken on your system because it doesn't do the access checks? I.e. you are claiming it is both working and broken:
It should only be readable by group locate (or mlocate--whatever), or root. Your installation has access control disabled because mlocate.db is world readable.
mlocate is *open source*, which means that if the "db" is readable by all, you can use your own, non-access checking version of mlocate to find files that you shouldn't be able to.
Only if the database is protected will mlocate enforce access control. I.e. mlocate-access checking is broken because the instructions are *right*, FOR the access-controlled version of mlocate. Your system is configured to disable those checks by having mlocate.db being world readable.
"You do not need to belong to that group, the instructions are plain wrong:" __[sic]__ "rpm -qi mlocate User must be member of locate group in order to use this package."
If you don't want to do access checks, then you don't need to be a member of group locate and the mlocate.db needs to be world readable.
If you want to do access checks, then you need mlocate SGID([m]locate) and the .db only readable by group [m]locate).
-
Carlos E. R. -
Carlos E. R. -
Linda Walsh -
Martin Pluskal -
Roman Bysh