Description of problem: msec does not like the avahi home directory arrangement. I don't know if this is a problem with avahi or with msec. I suspect that msec should not be looking at this issue when it involves system accounts as opposed to user accounts. But perhaps avahi has a problem. In any case it needs to be reviewed. Version-Release number of selected component (if applicable): How reproducible: View msec output to log: ================================================================ *** Security Check, May 06 07:51:55 *** *** Check type: daily *** *** Check executed from: /etc/cron.daily/msec *** Report summary: Test started: May 06 07:51:55 Test finished: May 06 07:51:58 Total of users whose home directories have unsafe permissions : 1 Total of open network ports: 12 Total of configured firewall rules: 84 Total local users: 31 Total local group: 55 Detailed report: Security Warning: these home directory should not be owned by someone else or writable : user=avahi(496) : home directory is owned by avahi-autoipd(495). ================================================================= Steps to Reproduce: 1. 2. 3. Reproducible: Steps to Reproduce:
Keywords: (none) => Junior_job
The issue with msec appears to be a symptom, not the actual problem itself. msec is complaining because two users, avahi, and avahi-autoipd have the same home directory /var/avahi /var/avahi would be an inappropriate location for a home directory so it is likely the avahi spec file is defective. From the spec file %pre %_pre_useradd %{name} %{_var}/%{name} /bin/false %_pre_useradd %{name}-autoipd %{_var}/%{name} /bin/false Comparing the Mageia spec file with Fedora's In Fedora user avahi has a home at /var/run/avahi-daemon and avahi-autoipd has home at /var/lib/avahi-autoipd /var/run/avahi-daemon and /var/lib/avahi-autoipd both exist in Mageia and are created when their respective daemons start.
Status: NEW => ASSIGNEDCC: (none) => derekjenn, jani.valimaaAssignee: bugsquad => derekjennSource RPM: msec-0.80.10-13.mga3.src.rpm => avahi-0.6.31-2.1.mga3.src.rpm
SRPMS: avahi-0.6.31-2.2.mga3.src.rpm is in core/updates_testing RPMS: avahi-0.6.31-2.2.mga3.i586.rpm avahi-0.6.31-2.2.mga3.x86_64.rpm Advisory ======== This update corrects a bug in avahi that caused the avahi user to use the wrong home directory. Test_Procedure ============== 1/ Install avahi from the normal repositories if it is not already installed. 2/ Issue the command getent passwd avahi Observe the /home directory is /var/avahi (last but one parameter) 3/ Update avahi to avahi-0.6.31-2.2.mga3 from core/updates_testing 4/ Issue getent command again. Observe home directory has changed to /var/run/avahi Note to QA: This update can be tested at the same time as Bug 10467
Hardware: i586 => AllAssignee: derekjenn => qa-bugs
Can you just assign one bug to QA for the update please Derek. It's OK to fix both things at once, just if there are two bugs assigned for the same update then one will get lost. The bug is closed as the update is pushed. Use either one of these two or create a new one, whichever way you prefer. Thanks.
Depends on: (none) => 10467
Depends on: 10467 => (none)
sorry for the typo. It is Bug 10469 this update depends on :-(
Depends on: (none) => 10469
Mga3 32 Followed instructions comment 2 results Avahi was already installed getent passwd avahi avahi:x:497:496:system user for avahi:/var/avahi:/bin/false Update to avahi-0.6.31-2.2.mga3 getent passwd avahi avahi:x:497:496:system user for avahi:/var/avahi:/bin/false Nothing has changed
CC: (none) => martynvidler
SRPMS: avahi-0.6.31-2.2.mga3.src.rpm is in core/updates_testing RPMS: avahi-0.6.31-2.2.mga3.i586.rpm avahi-0.6.31-2.2.mga3.x86_64.rpm Advisory ======== This update corrects a bug in avahi that caused the avahi user to use the wrong home directory. It also moves the dnsconfd systemd unit file to the avahi-dnsconfd subpackage. Note to QA: This update can be tested at the same time as Bug 10467 Test_Procedure ============== 1/ Install avahi from the normal repositories if it is not already installed. 2/ Issue the command getent passwd avahi Observe the /home directory is /var/avahi (last but one parameter) 3/ Update avahi to avahi-0.6.31-2.2.mga3 from core/updates_testing 4/ Issue getent command again. Observe home directory has changed to /var/run/avahi Test Procedure for bug 10469 ---------------------------- 1/ Uninstall avahi-dnsconfd if it is already installed 2/ Observe that the service avahi-dnsconfd is present in drakxservices and cannot be started. 3/ Enable updates/testing repository then urpmi avahi 4/ Observe the avahi-dnsconfd service is no longer present in drakxservices. 5/ urpmi-avahi-dnsconfd Observe that avahi-dnsconfd is now present in drakxservices and can be stopped and started. 6/ Finally if you have other zeroconf devices on your network demonstrate that avahi works with the command (as user) $ avahi-browse -at You should see a list of local and remote ssh/smb shares. (You may have to wait a few minutes after starting the service)
Oops copy paste error, should be.. Note to QA: This update can be tested at the same time as Bug 10469
could you list all rpms please Derek, seems there are at least libs included in avahi srpm.
(In reply to martyn vidler from comment #5) > Mga3 32 > > Followed instructions comment 2 results > > Avahi was already installed > > getent passwd avahi > avahi:x:497:496:system user for avahi:/var/avahi:/bin/false > > Update to avahi-0.6.31-2.2.mga3 > > getent passwd avahi > avahi:x:497:496:system user for avahi:/var/avahi:/bin/false > > Nothing has changed Martyn, Try with this sequence [root@Derek run]# rpm -e --nodeps avahi [root@Derek run]# userdel avahi [root@Derek run]# urpmi --media 'Core Release' avahi installing avahi-0.6.31-2.mga3.x86_64.rpm from /var/cache/urpmi/rpms [root@Derek run]# getent passwd avahi avahi:x:476:412:system user for avahi:/var/run/avahi:/bin/false The above gets you back to a standard installation. Now to install the update :- [root@Derek run]# urpmi --media 'Core Updates Testing' avahi installing avahi-0.6.31-2.2.mga3.x86_64.rpm from /var/cache/urpmi/rpms 1/1: removing avahi-0.6.31-2.mga3.x86_64 [root@Derek run]# getent passwd avahi avahi:x:476:412:system user for avahi:/var/run/avahi:/bin/false
(In reply to claire robinson from comment #8) > could you list all rpms please Derek, seems there are at least libs included > in avahi srpm. Claire, The update is just on the spec file, avahi itself is unchanged and should work just the same. But if you want to confirm avahi is functioning normally then install avahi avahi-dnsconfd libavahi-common3 libavahi-client3 Libararies for applications that depend on avahi are:- libavahi-common3 libavahi-compat-howl0 libavahi-compat-libdns_sd1 libavahi-core7 libavahi-glib1 libavahi-gobject0 libavahi-qt4_1 libavahi-ui-gtk3_0 libavahi-ui1
> Martyn, Try with this sequence > SNIP > > [root@Derek run]# getent passwd avahi > avahi:x:476:412:system user for avahi:/var/run/avahi:/bin/false > > The above gets you back to a standard installation. Now to install the > update :- Copy/paste malfunction That line should of course read [root@Derek run]# getent passwd avahi avahi:x:474:474:system user for avahi:/var/avahi:/bin/false
We at least have to make sure they update without issue Derek. They are all rebuilt regardless of the changes.
Just to be sure. Is /var/run/avahi really a correct path for avahi's homedir or should it be /var/run/avahi-daemon like it's in Fedora? Nothing seems to create /var/run/avahi.
(In reply to Jani Välimaa from comment #13) > Just to be sure. > > Is /var/run/avahi really a correct path for avahi's homedir or should it be > /var/run/avahi-daemon like it's in Fedora? Nothing seems to create > /var/run/avahi. As usual you are correct. Apologies. QA please wait for avahi-0.6.31-2.3.mga3 to hit updates_testing. To ensure your configuration is as for a new install when retesting follow this procedure #rpm -e --nodeps avahi # userdel avahi If you see the message :- userdel: user avahi is currently used by process xxxx then # kill -9 xxxx # getent passwd avahi avahi:x:474:474:system user for avahi:/var/avahi:/bin/false Now you are back to a default configuration install the update # urpmi --media 'Core Updates Testing' avahi installing avahi-0.6.31-2.3.mga3.x86_64.rpm # getent passwd avahi avahi:x:474:474:system user for avahi:/var/run/avahi-daemon:/bin/false
Thks David Tested on MGA3 32 Completed test as per comment 14 Results sudo getent passwd avahi avahi:x:486:478:system user for avahi:/var/avahi:/bin/false $MIRRORLIST: media/core/updates_testing/avahi-0.6.31-2.3.mga3.i586.rpm installing avahi-0.6.31-2.3.mga3.i586.rpm from /var/cache/urpmi/rpms Preparing... ######################################################## 1/1: avahi ######################################################## 1/1: removing avahi-0.6.31-2.mga3.i586 sudo getent passwd avahi avahi:x:486:478:system user for avahi:/var/run/avahi-daemon:/bin/false
Whiteboard: (none) => MGA3-32-ok
Tested as above MGA3 64 Completed as expected
Whiteboard: MGA3-32-ok => MGA3-32-ok MGA3-64-ok
Testing complete validating SRPMS: avahi-0.6.31-2.2.mga3.src.rpm is in core/updates_testing RPMS: avahi-0.6.31-2.2.mga3.i586.rpm avahi-0.6.31-2.2.mga3.x86_64.rpm Can sysadmin push from core_updates_testing to core_updates
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
http://svnweb.mageia.org/advisories/10004.adv?view=markup&sortby=date uploaded. Could someone from the sysadmin team push 10004.adv
CC: (none) => davidwhodgins
http://advisories.mageia.org/MGAA-2013-0044.html
Status: ASSIGNED => RESOLVEDCC: (none) => boklmResolution: (none) => FIXED
CC: boklm => (none)
Blocks: (none) => 15650
Hello, sorry for late reopening; I've just seen that my computer running Mageia 6 (upgraded from 5, upgraded from 4, upgraded from 3, etc...) still had 'avahi' user account using '/var/avahi' as home directory. When reinstalling 'avahi' package, the %preinstall script shows the following message: # urpmi --replacepkgs avahi usermod: user avahi is currently used by process 30287 Extract from current %preinstall script: # Correct home directories if users already exists (mga#10004) if [ "`grep -E '^avahi:' < /etc/passwd | cut -f6 -d:`" = /var/avahi ]; then /usr/sbin/usermod -d /var/run/avahi-daemon avahi fi I believe the 'usermod' command cannot succeed when the avahi-daemon is started, which is always the case when upgrading installed distribution using 'urpmi', which I do. Proposed solutions: 1) stop the 'avahi-daemon' service prior to running 'usermod' command. 2) check that home directory is correct after running usermod
Resolution: FIXED => (none)CC: (none) => albator78Status: RESOLVED => REOPENED
Closing this back down as it's an advisory that has gone out ~4 years ago. You need to open up a new report regarding this ...
Status: REOPENED => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED