[opensuse-support] updatedb now fails for regular user with local db
[os Leap 15, xfce] I have a private mlocate database in my /home. Since a few days ago attempting to update the db now fails for a command such as: "updatedb -l 0 -o /home/rsil/Downloads/rsildb -U /home/rsil" Message is: "updatedb: can not open a temporary file for `/home/rsil/Downloads/rsildb" There was an update to mlocate on 17 Nov, perhaps the culprit, or not. Whatever. How do I get back the ability to update my own database? Thanks. Ralph -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 2018-11-25 06:48 PM, Ralph wrote:
[os Leap 15, xfce]
I have a private mlocate database in my /home. Since a few days ago attempting to update the db now fails for a command such as:
"updatedb -l 0 -o /home/rsil/Downloads/rsildb -U /home/rsil"
Message is: "updatedb: can not open a temporary file for `/home/rsil/Downloads/rsildb"
There was an update to mlocate on 17 Nov, perhaps the culprit, or not. Whatever. How do I get back the ability to update my own database?
Thanks.
Ralph You can revert to the previous version in Yast/Software Management. Also you might want to mark it as "protected" (right click, select "Protected - Do Not Modify" in the popup) until the next update comes along.
To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On Sun, 25 Nov 2018 19:00:23 -0600 hadron <strange.charmed.antiquark@gmail.com> wrote:
On 2018-11-25 06:48 PM, Ralph wrote:
[os Leap 15, xfce]
I have a private mlocate database in my /home. Since a few days ago attempting to update the db now fails for a command such as:
"updatedb -l 0 -o /home/rsil/Downloads/rsildb -U /home/rsil"
Message is: "updatedb: can not open a temporary file for `/home/rsil/Downloads/rsildb"
There was an update to mlocate on 17 Nov, perhaps the culprit, or not. Whatever. How do I get back the ability to update my own database?
You can revert to the previous version in Yast/Software Management. Also you might want to mark it as "protected" (right click, select "Protected - Do Not Modify" in the popup) until the next update comes along.
Unfortunately does not work. Reverting to the other available version, from the original distro, also now fails. "Something" changed the permissions for something somewhere, and that's not reverted by reinstalling an old version. I could do a btrfs rollback to pre-Nov 17 but that seems a bit drastic for this particular problem, there have been a bunch of updates since that date that would also rollback. Ralph -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
* Ralph <suselist@cableone.net> [11-25-18 19:50]:
[os Leap 15, xfce]
I have a private mlocate database in my /home. Since a few days ago attempting to update the db now fails for a command such as:
"updatedb -l 0 -o /home/rsil/Downloads/rsildb -U /home/rsil"
Message is: "updatedb: can not open a temporary file for `/home/rsil/Downloads/rsildb"
There was an update to mlocate on 17 Nov, perhaps the culprit, or not. Whatever. How do I get back the ability to update my own database?
google for the error msg, iirc was incorrect perms for a directory -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On Sun, 25 Nov 2018 20:01:33 -0500 Patrick Shanahan <paka@opensuse.org> wrote:
- Ralph <suselist@cableone.net> [11-25-18 19:50]:
[os Leap 15, xfce]
I have a private mlocate database in my /home. Since a few days ago attempting to update the db now fails for a command such as:
"updatedb -l 0 -o /home/rsil/Downloads/rsildb -U /home/rsil"
Message is: "updatedb: can not open a temporary file for `/home/rsil/Downloads/rsildb"
There was an update to mlocate on 17 Nov, perhaps the culprit, or not. Whatever. How do I get back the ability to update my own database?
google for the error msg, iirc was incorrect perms for a directory
Did that. My google-fu is really weak but it seems the Nov 17 update to mlocate was to fix a problem with mlocate/updatedb permissions related to apparmor, and since that date is when my problems likely began then I assume that the "fix" broke something. That Nov 17 "fix" was: https://bugzilla.opensuse.org/show_bug.cgi?id=1089594 I'm having trouble following the logic of that bug chat as my knowledge of apparmor is slim to none, especially at 3:30 am here. What's it say there? 8-/ Ralph -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 26/11/2018 10.49, Ralph wrote:
On Sun, 25 Nov 2018 20:01:33 -0500 Patrick Shanahan <paka@opensuse.org> wrote:
- Ralph <suselist@cableone.net> [11-25-18 19:50]:
[os Leap 15, xfce]
I have a private mlocate database in my /home. Since a few days ago attempting to update the db now fails for a command such as:
"updatedb -l 0 -o /home/rsil/Downloads/rsildb -U /home/rsil"
Message is: "updatedb: can not open a temporary file for `/home/rsil/Downloads/rsildb"
There was an update to mlocate on 17 Nov, perhaps the culprit, or not. Whatever. How do I get back the ability to update my own database?
google for the error msg, iirc was incorrect perms for a directory
Did that. My google-fu is really weak but it seems the Nov 17 update to mlocate was to fix a problem with mlocate/updatedb permissions related to apparmor, and since that date is when my problems likely began then I assume that the "fix" broke something. That Nov 17 "fix" was:
https://bugzilla.opensuse.org/show_bug.cgi?id=1089594
I'm having trouble following the logic of that bug chat as my knowledge of apparmor is slim to none, especially at 3:30 am here. What's it say there? 8-/
Move the file "/etc/apparmor.d/usr.bin.locate" temporarily somewhere else, restart apparmour, and try again with locate. If it works, open a bugzilla. Alternative. Run "aa-logprof", hopefully it says something about something in locate being denied and gives you the chance to allow it. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
Hello, Am Montag, 26. November 2018, 11:24:33 CET schrieb Carlos E. R.:
On 26/11/2018 10.49, Ralph wrote:
On Sun, 25 Nov 2018 20:01:33 -0500
Patrick Shanahan <paka@opensuse.org> wrote:
- Ralph <suselist@cableone.net> [11-25-18 19:50]:
[os Leap 15, xfce]
I have a private mlocate database in my /home.
Nobody told me about that when I created and submitted an AppArmor profile for locate and updatedb ;-) This also means that I'm not surprised that you get a "permission denied" error.
Did that. My google-fu is really weak but it seems the Nov 17 update to mlocate was to fix a problem with mlocate/updatedb permissions related to apparmor,
I'd have to check the details, but I'm quite sure that this update added the AppArmor profile.
https://bugzilla.opensuse.org/show_bug.cgi?id=1089594
I'm having trouble following the logic of that bug chat as my knowledge of apparmor is slim to none, especially at 3:30 am here. What's it say there? 8-/
That bug was about adding the AppArmor profiles (as security improvement) and, starting at comment 4, that the updatedb profile needs some capabilities added that weren't part of the initial profile.
Move the file "/etc/apparmor.d/usr.bin.locate" temporarily somewhere else, restart apparmour, and try again with locate. If it works, open a bugzilla.
That won't work - reloading apparmor no longer unloads unknown profiles. You'll need to run aa-remove-unknown - but before you do that, check the release notes for details and the reason for this change. If you really want to disable a profile, use aa-disable, but I don't recommend that. Instead, switch the profile to complain (learning) mode with aa-complain, and after updating the profile, switch it back to enforce mode with aa-logprof.
Alternative.
Run "aa-logprof", hopefully it says something about something in locate being denied and gives you the chance to allow it.
Exactly, aa-logprof will help to update the profile easily. That said, you can also update the profiles manually: In /etc/apparmor.d/usr.bin.locate, add /home/rsil/Downloads/rsildb r, In /etc/apparmor.d/usr.bin.updatedb, add /home/rsil/Downloads/rsildb rwk, /home/rsil/Downloads/rsildb.?????? rw, Then run rcapparmor reload and everything should work as expected. Notice to myself: the updatedb and locate profiles should have a local/ include so that you don't need to modify the packaged profiles. Regards, Christian Boltz -- Was schlagen sie vor, Prof. Dr. cvs. Boltz? :-) [Ratti in fontlinge-devel] -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 26/11/2018 12.56, Christian Boltz wrote:
Hello,
Am Montag, 26. November 2018, 11:24:33 CET schrieb Carlos E. R.:
On 26/11/2018 10.49, Ralph wrote:
On Sun, 25 Nov 2018 20:01:33 -0500 Patrick Shanahan <> wrote:
- Ralph <> [11-25-18 19:50]:
[os Leap 15, xfce]
I have a private mlocate database in my /home.
Nobody told me about that when I created and submitted an AppArmor profile for locate and updatedb ;-)
This also means that I'm not surprised that you get a "permission denied" error.
:-)
Did that. My google-fu is really weak but it seems the Nov 17 update to mlocate was to fix a problem with mlocate/updatedb permissions related to apparmor,
I'd have to check the details, but I'm quite sure that this update added the AppArmor profile.
https://bugzilla.opensuse.org/show_bug.cgi?id=1089594
I'm having trouble following the logic of that bug chat as my knowledge of apparmor is slim to none, especially at 3:30 am here. What's it say there? 8-/
That bug was about adding the AppArmor profiles (as security improvement) and, starting at comment 4, that the updatedb profile needs some capabilities added that weren't part of the initial profile.
Move the file "/etc/apparmor.d/usr.bin.locate" temporarily somewhere else, restart apparmour, and try again with locate. If it works, open a bugzilla.
That won't work - reloading apparmor no longer unloads unknown profiles. You'll need to run aa-remove-unknown - but before you do that, check the release notes for details and the reason for this change.
Oh! (well, a reboot would work :-p )
If you really want to disable a profile, use aa-disable, but I don't recommend that.
Instead, switch the profile to complain (learning) mode with aa-complain, and after updating the profile, switch it back to enforce mode with aa-logprof.
Alternative.
Run "aa-logprof", hopefully it says something about something in locate being denied and gives you the chance to allow it.
Exactly, aa-logprof will help to update the profile easily.
I use that often. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On Mon, 26 Nov 2018 12:56:39 +0100 Christian Boltz <opensuse@cboltz.de> wrote:
Exactly, aa-logprof will help to update the profile easily.
I didn't understand the options in aa-logprof so I followed your manual instructions:
That said, you can also update the profiles manually:
In /etc/apparmor.d/usr.bin.locate, add /home/rsil/Downloads/rsildb r,
In /etc/apparmor.d/usr.bin.updatedb, add /home/rsil/Downloads/rsildb rwk, /home/rsil/Downloads/rsildb.?????? rw,
Then run rcapparmor reload and everything should work as expected.
This didn't work. The messages are now gone from aa-logprof, but running: "updatedb -l 0 -o /home/rsil/Downloads/rsildb -U /home/rsil" ...still gives me the message: "updatedb: can not open a temporary file for `/home/rsil/Downloads/rsildb'" I checked my entries for any typos but all is good there...? Ralph -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
Hello, Am Dienstag, 27. November 2018, 16:00:33 CET schrieb Ralph:
On Mon, 26 Nov 2018 12:56:39 +0100 Christian Boltz <opensuse@cboltz.de> wrote:
Exactly, aa-logprof will help to update the profile easily.
I didn't understand the options in aa-logprof so I followed your manual instructions:
What exactly in aa-logprof was hard to understand? I'm always open for improvements ;-)
That said, you can also update the profiles manually: [...] Then run rcapparmor reload and everything should work as expected. This didn't work. The messages are now gone from aa-logprof, but running:
"updatedb -l 0 -o /home/rsil/Downloads/rsildb -U /home/rsil"
...still gives me the message:
"updatedb: can not open a temporary file for `/home/rsil/Downloads/rsildb'"
I checked my entries for any typos but all is good there...?
Maybe you need additional permissions I didn't guess from just reading and adjusting the profiles. Start tail -f /var/log/audit/audit.log as root and try updatedb again. You'll probably get some log entries - just paste them (in your next mail or paste.opensuse.org, depending on the size) so that I can see what's going on. You can/should also run aa-complain /etc/apparmor.d/usr.bin.updatedb to switch the profile to learning mode so that we see everything that would be denied instead of only the first issue. Don't forget to switch the profile back to enforce mode with aa-enforce when it's updated ;-) Just to be sure, even if if sounds unlikely - did you check the owner and directory permissions of /home/rsil/Downloads/ and the owner and permissions of the existing "rsildb*" file(s)? If the filesystem permissions deny access, AppArmor won't change anything ;-) Regards, Christian Boltz -- <cboltz> jjohansen: you are making it too easy for kshitij8 ;-) <jjohansen> cboltz: oops sorry, now I'll have to come up with a new task to make him suffer :) <sarnold> review the c++11 conversion? :) * sarnold runs <jjohansen> haha, sarnold I said suffer, not drive him to commit suicide [from #apparmor] -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On Tue, 27 Nov 2018 19:43:32 +0100 Christian Boltz <opensuse@cboltz.de> wrote:
I didn't understand the options in aa-logprof so I followed your manual instructions:
What exactly in aa-logprof was hard to understand? I'm always open for improvements ;-)
Probably nothing at all wrong with your prog, but I did not have time to read the man page yet. I was shown a list of profiles (3?), one with wildcards, and had no idea which one even to deal with, or maybe it was all 3 to be worked. I also tried the gui version of it with same "what do I do here" result.
That said, you can also update the profiles manually: [...] Then run rcapparmor reload and everything should work as expected. This didn't work. The messages are now gone from aa-logprof, but running:
"updatedb -l 0 -o /home/rsil/Downloads/rsildb -U /home/rsil"
...still gives me the message:
"updatedb: can not open a temporary file for `/home/rsil/Downloads/rsildb'"
I checked my entries for any typos but all is good there...?
Maybe you need additional permissions I didn't guess from just reading and adjusting the profiles.
Start tail -f /var/log/audit/audit.log as root and try updatedb again. You'll probably get some log entries - just paste them (in your next mail or paste.opensuse.org, depending on the size) so that I can see what's going on.
The paste is at: http://paste.opensuse.org/d3ec73bc
You can/should also run aa-complain /etc/apparmor.d/usr.bin.updatedb to switch the profile to learning mode so that we see everything that would be denied instead of only the first issue. Don't forget to switch the profile back to enforce mode with aa-enforce when it's updated ;-)
No opportunity for this yet...
Just to be sure, even if if sounds unlikely - did you check the owner and directory permissions of /home/rsil/Downloads/ and the owner and permissions of the existing "rsildb*" file(s)? If the filesystem permissions deny access, AppArmor won't change anything ;-)
Entire /home/rsil is restricted to owner, rw(x). No rights/access to group or others. The db is -rw------- and the directories path to it are all drwx------. Thanks for the assistance. Ralph -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 28/11/2018 00.00, Ralph wrote:
On Tue, 27 Nov 2018 19:43:32 +0100 Christian Boltz <opensuse@cboltz.de> wrote:
I didn't understand the options in aa-logprof so I followed your manual instructions:
What exactly in aa-logprof was hard to understand? I'm always open for improvements ;-)
Probably nothing at all wrong with your prog, but I did not have time to read the man page yet.
I have not read it. You don't have to use any options at all.
I was shown a list of profiles (3?), one with wildcards, and had no idea which one even to deal with, or maybe it was all 3 to be worked. I also tried the gui version of it with same "what do I do here" result.
Just copy that screen here and I'll tell you which to choose. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On Wed, 28 Nov 2018 03:02:59 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
I was shown a list of profiles (3?), one with wildcards, and had no idea which one even to deal with, or maybe it was all 3 to be worked. I also tried the gui version of it with same "what do I do here" result.
Just copy that screen here and I'll tell you which to choose.
There's nothing there now, after I manually edited the files as told. I'm still DENIED during fresh db access tries, as per the log I posted, but aa-logprof now just says: dellT3620:~ # aa-logprof Reading log entries from /var/log/audit/audit.log. Updating AppArmor profiles in /etc/apparmor.d. Enforce-mode changes: dellT3620:~ # Ralph -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 28/11/2018 03.25, Ralph wrote:
On Wed, 28 Nov 2018 03:02:59 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
I was shown a list of profiles (3?), one with wildcards, and had no idea which one even to deal with, or maybe it was all 3 to be worked. I also tried the gui version of it with same "what do I do here" result.
Just copy that screen here and I'll tell you which to choose.
There's nothing there now, after I manually edited the files as told. I'm still DENIED during fresh db access tries, as per the log I posted, but aa-logprof now just says:
dellT3620:~ # aa-logprof Reading log entries from /var/log/audit/audit.log. Updating AppArmor profiles in /etc/apparmor.d. Enforce-mode changes: dellT3620:~ #
Well, if it is apparmor, the thing to do is put the profile in complain mode and see the log. I tried your method in my desktop computer, and it works: cer@Telcontar:~> updatedb -l 0 -o /home/cer/Downloads/updatedb -U /home/cer cer@Telcontar:~> l /home/cer/Downloads/updatedb -rw-r--r-- 1 cer users 8195214 Nov 28 12:31 /home/cer/Downloads/updatedb cer@Telcontar:~> updatedb -l 0 -o /home/cer/Downloads/updatedb -U /home/cer cer@Telcontar:~> However: cer@Telcontar:~> l /home/cer/Downloads/updatedb -rw-r--r-- 1 cer users 8195258 Nov 28 12:35 /home/cer/Downloads/updatedb cer@Telcontar:~> chmod g-r,o-r /home/cer/Downloads/updatedb cer@Telcontar:~> l /home/cer/Downloads/updatedb -rw------- 1 cer users 8195258 Nov 28 12:35 /home/cer/Downloads/updatedb cer@Telcontar:~> updatedb -l 0 -o /home/cer/Downloads/updatedb -U /home/cer cer@Telcontar:~> l /home/cer/Downloads/updatedb -rw-r--r-- 1 cer users 8195323 Nov 28 12:36 /home/cer/Downloads/updatedb cer@Telcontar:~> As you can see, updatedb changes the permissions. cer@Telcontar:~> chmod g-r-x,o-r-x /home/cer/Downloads/ cer@Telcontar:~> chmod g-r,o-r /home/cer/Downloads/updatedb cer@Telcontar:~> updatedb -l 0 -o /home/cer/Downloads/updatedb -U /home/cer cer@Telcontar:~> l /home/cer/Downloads/updatedb -rw-r--r-- 1 cer users 8195347 Nov 28 12:38 /home/cer/Downloads/updatedb cer@Telcontar:~> Maybe the apparmor update does not apply to oS 42.3. I'll try later in another machine with 15.0 -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
Hello, Am Mittwoch, 28. November 2018, 03:25:44 CET schrieb Ralph:
There's nothing there now, after I manually edited the files as told. I'm still DENIED during fresh db access tries, as per the log I posted, but aa-logprof now just says:
dellT3620:~ # aa-logprof Reading log entries from /var/log/audit/audit.log. Updating AppArmor profiles in /etc/apparmor.d. Enforce-mode changes: dellT3620:~ #
That means the profiles now allow everything you have in the audit.log, but for some reason the kernel doesn't know the updated profiles. [1] Did you run "rcapparmor reload" after editing the profiles? If "rcapparmor reload" doesn't help, please paste the output of the following commands: grep -r /usr/bin/updatedb /etc/apparmor.d/ grep -r /usr/bin/locate /etc/apparmor.d/ grep -r /home/rsil/Downloads/rsildb /etc/apparmor.d/ (My guess is that you might have a backup copy of the original profile, which gets loaded after the updated profile and replaces it.) Regards, Christian Boltz [1] There's also the option that aa-logprof doesn't understand some of your audit.log entries, but this isn't the case here - file events are fully supported. -- Yeah, I always need to have a sick bag handy when thinking about web apps ;-) [Ludwig Nussel in opensuse-packaging] -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On Wed, 28 Nov 2018 12:44:11 +0100 Christian Boltz <opensuse@cboltz.de> wrote:
(My guess is that you might have a backup copy of the original profile, which gets loaded after the updated profile and replaces it.)
Well, very very good "guessing", you nailed it perfectly. dellT3620:~> grep -r /usr/bin/updatedb /etc/apparmor.d/ /etc/apparmor.d/usr.bin.updatedb.orig:/usr/bin/updatedb { /etc/apparmor.d/usr.bin.updatedb.orig: /usr/bin/updatedb mr, /etc/apparmor.d/usr.bin.updatedb:/usr/bin/updatedb { /etc/apparmor.d/usr.bin.updatedb: /usr/bin/updatedb mr, Moving the .orig backup file elsewhere, and doing the same for locate.orig file, then another "rcapparmor reload", and all is seemingly back to normal, update and locate both work fine on the local db. I guess I am going to have to change my method of naming backup copies of edited system files :-/ Thank you very much! Ralph -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
Hello, Am Mittwoch, 28. November 2018, 14:27:06 CET schrieb Ralph:
On Wed, 28 Nov 2018 12:44:11 +0100 Christian Boltz <opensuse@cboltz.de> wrote:
(My guess is that you might have a backup copy of the original profile, which gets loaded after the updated profile and replaces it.) Well, very very good "guessing", you nailed it perfectly.
Well, let's say I didn't have to guess that for the first time ;-)
dellT3620:~> grep -r /usr/bin/updatedb /etc/apparmor.d/ /etc/apparmor.d/usr.bin.updatedb.orig:/usr/bin/updatedb { /etc/apparmor.d/usr.bin.updatedb.orig: /usr/bin/updatedb mr, /etc/apparmor.d/usr.bin.updatedb:/usr/bin/updatedb { /etc/apparmor.d/usr.bin.updatedb: /usr/bin/updatedb mr,
Moving the .orig backup file elsewhere, and doing the same for locate.orig file, then another "rcapparmor reload", and all is seemingly back to normal, update and locate both work fine on the local db.
I'm happy to hear that :-)
I guess I am going to have to change my method of naming backup copies of edited system files :-/
For AppArmor profiles, the best strategy is to move them out of /etc/apparmor.d/ (actually I'd recommend that for all /etc/whatever.d/ directories) Since Carlos asked - suffixes that get ignored by the AppArmor tools (aa-logprof etc.) are: aa.py: skippable_suffix = ( '.dpkg-new', '.dpkg-old', '.dpkg-dist', '.dpkg-bak', '.dpkg-remove', '.pacsave', '.pacnew', '.rpmnew', '.rpmsave', '.orig', '.rej', '~' ) libapparmor (and apparmor_parser, if you give a directory as parameter) also ignores these suffixes. However, you accidently found a bug ;-) - the script that loads the profiles doesn't ignore *.orig and *.rej files. I just submitted https://gitlab.com/apparmor/apparmor/merge_requests/282 so that the next maintenance release will fix this. (As a sidenote - if you'd have used a not-ignored extension for your backup file, aa-logprof would have complained about having two profiles for the same program.) Regards, Christian Boltz --
Anschließend schaltest du deinen PC aus und hängst dich auf. Oder umgekehrt Nach reiflicher Überlegung habe ich meinen PC an die Decke gehängt, kann aber jetzt meinen Ausschalter nicht finden. Was mache ich falsch? [Dieter Bruegmann und Eugen Schabenberger in dag°]
-- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 28/11/2018 23.04, Christian Boltz wrote:
Hello,
Am Mittwoch, 28. November 2018, 14:27:06 CET schrieb Ralph:
...
I guess I am going to have to change my method of naming backup copies of edited system files :-/
For AppArmor profiles, the best strategy is to move them out of /etc/apparmor.d/ (actually I'd recommend that for all /etc/whatever.d/ directories)
Since Carlos asked - suffixes that get ignored by the AppArmor tools (aa-logprof etc.) are:
aa.py: skippable_suffix = ( '.dpkg-new', '.dpkg-old', '.dpkg-dist', '.dpkg-bak', '.dpkg-remove', '.pacsave', '.pacnew', '.rpmnew', '.rpmsave', '.orig', '.rej', '~' )
Ah, jstar uses '~' so I'm safe :-) May I suggest you add ".bak"? I think some editors use it, but I don't know which.
libapparmor (and apparmor_parser, if you give a directory as parameter) also ignores these suffixes.
However, you accidently found a bug ;-) - the script that loads the profiles doesn't ignore *.orig and *.rej files. I just submitted https://gitlab.com/apparmor/apparmor/merge_requests/282 so that the next maintenance release will fix this.
Ah
(As a sidenote - if you'd have used a not-ignored extension for your backup file, aa-logprof would have complained about having two profiles for the same program.)
Well, that's good, it detect duplicates. I think I have experienced this some time in the past. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 28/11/2018 12.44, Christian Boltz wrote:
Hello,
If "rcapparmor reload" doesn't help, please paste the output of the following commands:
grep -r /usr/bin/updatedb /etc/apparmor.d/ grep -r /usr/bin/locate /etc/apparmor.d/ grep -r /home/rsil/Downloads/rsildb /etc/apparmor.d/
(My guess is that you might have a backup copy of the original profile, which gets loaded after the updated profile and replaces it.)
which backup file extensions, if any, get ignored? I have: /etc/apparmor.d/usr.bin.updatedb~ /etc/apparmor.d/usr.bin.updatedb If the backups are not ignored, then we must remember to delete them manually. I didn't know about that. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 27/11/2018 16.00, Ralph wrote:
On Mon, 26 Nov 2018 12:56:39 +0100 Christian Boltz <opensuse@cboltz.de> wrote:
Exactly, aa-logprof will help to update the profile easily.
I didn't understand the options in aa-logprof so I followed your manual instructions:
You do not need to add options in the command line to call "aa-logprof" - you just call it. The problem may be later in the questions it asks. Basically it says that read or write access to some file or directory was denied, and you decide what to do: allow it, deny it always. And you can choose to apply on that exact file name or on some pattern (glob). Finally, it asks whether to write your changes. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 26/11/2018 12.56, Christian Boltz wrote:
Hello,
Am Montag, 26. November 2018, 11:24:33 CET schrieb Carlos E. R.:
...
Alternative.
Run "aa-logprof", hopefully it says something about something in locate being denied and gives you the chance to allow it.
Exactly, aa-logprof will help to update the profile easily.
I tried in a 15.0 machine recently updated, and I got added: owner /home/*/Downloads/updatedb w, owner /home/*/Downloads/updatedb.* r, owner /home/*/Downloads/updatedb.* w, owner /home/*/Downloads/updatedb.*J w, owner /home/cer/Downloads/updatedb.??????J w, The "???" is because on the rest I used "*" instead to save typing. The "J" I have no idea. Fat finger? Alt-tab junk? Ok, I edited it manually, and the result is: ... owner /home/*/Downloads/updatedb w, owner /home/*/Downloads/updatedb.?????? rw, And the command works: cer@Legolas:~> updatedb -l 0 -o /home/cer/Downloads/updatedb -U /home/cer cer@Legolas:~> -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
* Ralph <suselist@cableone.net> [11-26-18 04:51]:
On Sun, 25 Nov 2018 20:01:33 -0500 Patrick Shanahan <paka@opensuse.org> wrote:
- Ralph <suselist@cableone.net> [11-25-18 19:50]:
[os Leap 15, xfce]
I have a private mlocate database in my /home. Since a few days ago attempting to update the db now fails for a command such as:
"updatedb -l 0 -o /home/rsil/Downloads/rsildb -U /home/rsil"
Message is: "updatedb: can not open a temporary file for `/home/rsil/Downloads/rsildb"
There was an update to mlocate on 17 Nov, perhaps the culprit, or not. Whatever. How do I get back the ability to update my own database?
google for the error msg, iirc was incorrect perms for a directory
Did that. My google-fu is really weak but it seems the Nov 17 update to mlocate was to fix a problem with mlocate/updatedb permissions related to apparmor, and since that date is when my problems likely began then I assume that the "fix" broke something. That Nov 17 "fix" was:
https://bugzilla.opensuse.org/show_bug.cgi?id=1089594
I'm having trouble following the logic of that bug chat as my knowledge of apparmor is slim to none, especially at 3:30 am here. What's it say there? 8-/
you are running updatedb as root? do you have: # ls -la /var/lib/mlocate drwxrwxr-x 2 nobody root 4096 Nov 25 18:00 ./ drwxr-xr-x 58 root root 4096 Nov 22 22:42 ../ -rw-r--r-- 1 nobody nobody 110210048 Nov 25 18:00 mlocate.db if not, as root # chown nobody:nobody /var/lib/mlocate/ # chmod 775 /var/lib/mlocate from google https://ubuntuforums.org/showthread.php?t=843389 If that is not the problem, the last comment in the bug report, https://bugzilla.opensuse.org/show_bug.cgi?id=1089594 openSUSE-RU-2018:3779-1: An update that has one recommended fix can now be installed. Category: recommended (moderate) Bug References: 1089594 CVE References: Sources used: openSUSE Leap 15.0 (src): mlocate-0.26-lp150.3.3.1 are you using at least that version of mlocate? if not you merely need to update. available: https://download.opensuse.org/update/leap/15.0/oss/x86_64/mlocate-0.26-lp150... https://download.opensuse.org/repositories/server:/search/openSUSE_Leap_15.0... -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
* Patrick Shanahan <paka@opensuse.org> [11-26-18 08:25]:
- Ralph <suselist@cableone.net> [11-26-18 04:51]:
On Sun, 25 Nov 2018 20:01:33 -0500 Patrick Shanahan <paka@opensuse.org> wrote:
- Ralph <suselist@cableone.net> [11-25-18 19:50]:
[os Leap 15, xfce]
I have a private mlocate database in my /home. Since a few days ago attempting to update the db now fails for a command such as:
"updatedb -l 0 -o /home/rsil/Downloads/rsildb -U /home/rsil"
Message is: "updatedb: can not open a temporary file for `/home/rsil/Downloads/rsildb"
There was an update to mlocate on 17 Nov, perhaps the culprit, or not. Whatever. How do I get back the ability to update my own database?
google for the error msg, iirc was incorrect perms for a directory
Did that. My google-fu is really weak but it seems the Nov 17 update to mlocate was to fix a problem with mlocate/updatedb permissions related to apparmor, and since that date is when my problems likely began then I assume that the "fix" broke something. That Nov 17 "fix" was:
https://bugzilla.opensuse.org/show_bug.cgi?id=1089594
I'm having trouble following the logic of that bug chat as my knowledge of apparmor is slim to none, especially at 3:30 am here. What's it say there? 8-/
you are running updatedb as root?
do you have: # ls -la /var/lib/mlocate drwxrwxr-x 2 nobody root 4096 Nov 25 18:00 ./ drwxr-xr-x 58 root root 4096 Nov 22 22:42 ../ -rw-r--r-- 1 nobody nobody 110210048 Nov 25 18:00 mlocate.db
if not, as root # chown nobody:nobody /var/lib/mlocate/ # chmod 775 /var/lib/mlocate
from google https://ubuntuforums.org/showthread.php?t=843389
If that is not the problem, the last comment in the bug report, https://bugzilla.opensuse.org/show_bug.cgi?id=1089594
openSUSE-RU-2018:3779-1: An update that has one recommended fix can now be installed.
Category: recommended (moderate) Bug References: 1089594 CVE References: Sources used: openSUSE Leap 15.0 (src): mlocate-0.26-lp150.3.3.1
are you using at least that version of mlocate?
if not you merely need to update. available: https://download.opensuse.org/update/leap/15.0/oss/x86_64/mlocate-0.26-lp150... https://download.opensuse.org/repositories/server:/search/openSUSE_Leap_15.0...
and perhaps my failing to read *completely* your question is another problem. "updatedb" is NOT intended to be performed by non-root user on openSUSE distro and has not in the past to my knowledge for a very long time. but you must account for brown-bottle pickled and aged memory. you must use "sudo" or otherwise elevate users privileges to root. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 26/11/2018 14.34, Patrick Shanahan wrote:
and perhaps my failing to read *completely* your question is another problem. "updatedb" is NOT intended to be performed by non-root user on openSUSE distro and has not in the past to my knowledge for a very long time. but you must account for brown-bottle pickled and aged memory. you must use "sudo" or otherwise elevate users privileges to root.
Sure you can :-) You can run it as "nobody" or "root". See the system config file entries: /etc/sysconfig/locate: ## Type: string(nobody, root, ...) ## Default: nobody # # updatedb has a parameter "--localuser". # It runs the "find" command as this user. Some people think this is a # security hole if set to 'root' (because some directory information can # be read which is normally protected). Others think it is useful to hold # all files in the database. # So if you want full information in locate db, set RUN_UPDATEDB_AS=root. # If you want security use RUN_UPDATEDB_AS=nobody. # RUN_UPDATEDB_AS="root" #RUN_UPDATEDB_AS="nobody" You can write there any user you like :-) What Ralph has done different is storing the database on home. Obviously, the program does support it: -o, --output FILE Write the database to FILE instead of using the default database. It was the apparmour profile which did not contemplate this possibility. I see some advantage running and storing as user: others have not access to it, but you do, full access. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On Mon, 26 Nov 2018 08:34:12 -0500 Patrick Shanahan <paka@opensuse.org> wrote:
and perhaps my failing to read *completely* your question is another problem. "updatedb" is NOT intended to be performed by non-root user on openSUSE distro and has not in the past to my knowledge for a very long time. but you must account for brown-bottle pickled and aged memory. you must use "sudo" or otherwise elevate users privileges to root.
What can I say, as time goes by I'm finding that LOTS of things I do by habit on linux, as a user, things that I have done since the last century, are all of a sudden "not supported by" whatever distro. A year(?) ago I was told by opensuse bugzilla folks that booting with the root partition in the extended partition on bios drives isn't supported, but I've been doing that on every/all of my machines since forever (except for one new uefi machine bought last year). Anyway, in this case, updatedb-for-users IS explained in the man pages, down near the bottom, one of the examples, which is probably where I originally got it from. The current man page is recent, well, recent as man pages go, dated 2008, but it's still there. If it's not supported then the man page should be changed. Ralph -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 28/11/2018 03.11, Ralph wrote:
On Mon, 26 Nov 2018 08:34:12 -0500 Patrick Shanahan <paka@opensuse.org> wrote:
and perhaps my failing to read *completely* your question is another problem. "updatedb" is NOT intended to be performed by non-root user on openSUSE distro and has not in the past to my knowledge for a very long time. but you must account for brown-bottle pickled and aged memory. you must use "sudo" or otherwise elevate users privileges to root.
What can I say, as time goes by I'm finding that LOTS of things I do by habit on linux, as a user, things that I have done since the last century, are all of a sudden "not supported by" whatever distro. A year(?) ago I was told by opensuse bugzilla folks that booting with the root partition in the extended partition on bios drives isn't supported, but I've been doing that on every/all of my machines since forever (except for one new uefi machine bought last year).
That's absurd, YaST installed the system automatically in that way for me years ago.
Anyway, in this case, updatedb-for-users IS explained in the man pages, down near the bottom, one of the examples, which is probably where I originally got it from. The current man page is recent, well, recent as man pages go, dated 2008, but it's still there. If it's not supported then the man page should be changed.
Yep. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 28/11/2018 03:11, Ralph wrote:
What can I say, as time goes by I'm finding that LOTS of things I do by habit on linux, as a user, things that I have done since the last century, are all of a sudden "not supported by" whatever distro.
Yes, agreed. On the other hand, I try to take some reassurance from it. It means that the OS is not fossilized, and is actively being changed and improved. But when systemd means that my laptop fails to boot, rather than simple going "oh, I can't mount the Windows partition, I will just keep on going without it", it's very hard to feel like that.
A year(?) ago I was told by opensuse bugzilla folks that booting with the root partition in the extended partition on bios drives isn't supported, but I've been doing that on every/all of my machines since forever
What?! Really? :-o -- Liam Proven - Technical Writer, SUSE Linux s.r.o. Corso II, Křižíkova 148/34, 186-00 Praha 8 - Karlín, Czechia Email: lproven@suse.com - Office telephone: +420 284 241 084 -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
participants (6)
-
Carlos E. R. -
Christian Boltz -
hadron -
Liam Proven -
Patrick Shanahan -
Ralph