On Sun, 25 Nov 2018 19:00:23 -0600 hadron 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

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. 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

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. 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 Mon, 26 Nov 2018 12:56:39 +0100 Christian Boltz 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

On Tue, 27 Nov 2018 19:43:32 +0100 Christian Boltz 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 Wed, 28 Nov 2018 03:02:59 +0100 "Carlos E. R." 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

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

Hello, Am Mittwoch, 28. November 2018, 14:27:06 CET schrieb Ralph:

On Wed, 28 Nov 2018 12:44:11 +0100 Christian Boltz 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 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 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)

* Patrick Shanahan [11-26-18 08:25]:

* Ralph [11-26-18 04:51]:

...

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. 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 Mon, 26 Nov 2018 08:34:12 -0500 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.

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:

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