Dear Fedora enthusiasts, I have been doing backup of my system using a custom pair of scripts. One sits in ./NetworkManager/dispatcher.d/ and looks at new network connections. If it sees one machine some criteria it calls a backup script in /etc/cron.daily/ which rsyncs various directories between my laptop and a desktop machine. This worked will in F17 and many previous versions. In F18 the rsync command fails to connect: dbus-daemon[938]: Could not create directory '/root/.ssh'. dbus-daemon[938]: Host key verification failed.
If I run either of the scripts as root interactively then they work. But not when NetworkManager tries to run them. Any idea what might be wrong? Both end already have /root/.ssh, so this error confuses me. Thanks! Bill
Allegedly, on or about 23 January 2013, William Murray sent:
in ./NetworkManager/dispatcher.d/ and looks at new network connections. If it sees one machine some criteria it calls a backup script in /etc/cron.daily/ which rsyncs various directories between my laptop and a desktop machine. This worked will in F17 and many previous versions. In F18 the rsync command fails to connect: dbus-daemon[938]: Could not create directory '/root/.ssh'. dbus-daemon[938]: Host key verification failed.
If I run either of the scripts as root interactively then they work. But not when NetworkManager tries to run them. Any idea what might be wrong? Both end already have /root/.ssh, so this error confuses me.
First thought: The scripts run by the dispatcher probably aren't being run as the root user.
Second thought, unrelated to the problem, but a common enough gotcha for any automatically run scripts: Sometimes scripts don't run in the same environment as you're used to, as a user. So it can be better to write the full path to any command, rather than just use the command name, and hope that it's in the search path of the script's environment. /bin probably is, but you never know with /sbin, and the various ones inside /usr.
Thanks>>
On 23/01/13 08:26, William Murray wrote:Allegedly, on or about 23 January 2013, William Murray sent:
/ in ./NetworkManager/dispatcher.d/ and looks at new network
/>>/ connections. />>/ If it sees one machine some criteria it calls a backup script />>/ in /etc/cron.daily/ which rsyncs various directories between my laptop />>/ and a desktop machine. This worked will in F17 and many />>/ previous versions. />>/ In F18 the rsync command fails to connect: />>/ dbus-daemon[938]: Could not create directory '/root/.ssh'. />>/ dbus-daemon[938]: Host key verification failed. />>/ />>/ If I run either of the scripts as root interactively then they work. />>/ But not when NetworkManager tries to run them. Any idea what might be />>/ wrong? Both end already have /root/.ssh, so this error confuses me. />
First thought: The scripts run by the dispatcher probably aren't being run as the root user.
Thanks...I tried echoing the output of 'whois' but that says root.
Second thought, unrelated to the problem, but a common enough gotcha for any automatically run scripts: Sometimes scripts don't run in the same environment as you're used to, as a user. So it can be better to write the full path to any command, rather than just use the command name, and hope that it's in the search path of the script's environment. /bin probably is, but you never know with /sbin, and the various ones inside /usr.
The thing is that rsync is being run - does it matter how?. I dug a bit deeper though, and turned up the debug on sshd on the server, and diffed the output.
I see 'good' and 'bad' attempts are the same up to "expecting SSH2_MGG_NEWKEYS received [preauth]" but that then a login launched by NetworkManager says "Connection closed by XXX.YYY.ZZZ.??? [preauth]" while one from me logged in as root says: "SSH2_MGG_NEWKEYS received [preauth]"
Does this give any clues? Bill
On Wed, 23 Jan 2013 18:53:31 +0100 William Murray wrote:
"Connection closed by XXX.YYY.ZZZ.??? [preauth]"
That was one of the errors I was seeing which led me to start this thread:
http://lists.fedoraproject.org/pipermail/users/2013-January/429506.html
(but I was always failing to connect, not merely sometimes failing).
On Wed, 23 Jan 2013 18:53:31 +0100 William Murray wrote:
/ "Connection closed by XXX.YYY.ZZZ.??? [preauth]"
/>
That was one of the errors I was seeing which led me to start this thread:
http://lists.fedoraproject.org/pipermail/users/2013-January/429506.html http://lists.fedoraproject.org/pipermail/users/2013-January/429506.html
(but I was always failing to connect, not merely sometimes failing).
Thanks Tom, That looked very promising - but actually doesn't seem to change anything. I relabelled them though...
I did spot something else though. I have this backup script running in /etc/cron.daily and so it runs once a day as well as whenever I plug in the correct cable. That version works! So when called (directly) by cron it runs, when called (indirectly) by NetworkManager it doesn't. Directly or indirectly by me it doesn't...
This is very confusing. Bill
On 01/22/2013 11:26 PM, William Murray wrote:
In F18 the rsync command fails to connect:
dbus-daemon[938]: Could not create directory '/root/.ssh'. dbus-daemon[938]: Host key verification failed.
Check /var/log/audit/audit.log. SELinux is probably denying access to the script in networkmanager's context.
In F18 the rsync command fails to connect: dbus-daemon[938]: Could not create directory '/root/.ssh'. dbus-daemon[938]: Host key verification failed.
Check /var/log/audit/audit.log. SELinux is probably denying access to the script in networkmanager's context.
Dear Gordon, Thanks, thats it. I put selinux on permissive in the client, and got 258 selinux warnings, but my files are backed up again.
I tidied a lot like this: grep rsync /var/log/audit/audit.log | audit2allow -M mypol semodule -i mypol.pp setsebool -P rsync_export_all_ro 1
I'm switiching on selinux and rebooting... Thanks! Bill
On 28/01/13 09:54, William Murray wrote:
In F18 the rsync command fails to connect: dbus-daemon[938]: Could not create directory '/root/.ssh'. dbus-daemon[938]: Host key verification failed.
Check /var/log/audit/audit.log. SELinux is probably denying access to the script in networkmanager's context.
Dear Gordon, Thanks, thats it. I put selinux on permissive in the client, and got 258 selinux warnings, but my files are backed up again.
I tidied a lot like this: grep rsync /var/log/audit/audit.log | audit2allow -M mypol semodule -i mypol.pp setsebool -P rsync_export_all_ro 1
I'm switiching on selinux and rebooting... Thanks! Bill
Alas, running with selinux on just causes NetworkManager to time out - and no feedback is SELinux alert browser.
-- Bill Murray ---- ATLAS STFC RAL at: Bat 40 4-C28, CERN,1211 Meyrin, Geneve 23, Switzerland Tel:- CERN +41 22 7678432 or RAL +44 (0)1235 446256
-- Scanned by iCritical.
On 01/28/2013 12:54 AM, William Murray wrote:
Thanks, thats it. I put selinux on permissive in the client, and got 258 selinux warnings, but my files are backed up again.
I tidied a lot like this: grep rsync /var/log/audit/audit.log | audit2allow -M mypol
Don't do that. I see something like that frequently given as advice for generating a policy, but it'll only work if rsync is the only thing that's being denied (or something else in an rsync context). From your original email, you're probably seeing at least one denial to ssh in NetworkManager's context.
Instead, put selinux into permissive mode. Rotate the audit log, or just use 'tail -f audit.log > mypol.avcs'. Run through all of the things that need to happen during normal operation. When that's done, you can use mypol.avcs or the rotated audit.log to generate the new policy.
setsebool -P rsync_export_all_ro 1
That's only necessary if you're running rsyncd, which I think you're not.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/28/2013 04:36 AM, Gordon Messmer wrote:
On 01/28/2013 12:54 AM, William Murray wrote:
Thanks, thats it. I put selinux on permissive in the client, and got 258 selinux warnings, but my files are backed up again.
I tidied a lot like this: grep rsync /var/log/audit/audit.log | audit2allow -M mypol
Don't do that. I see something like that frequently given as advice for generating a policy, but it'll only work if rsync is the only thing that's being denied (or something else in an rsync context). From your original email, you're probably seeing at least one denial to ssh in NetworkManager's context.
Instead, put selinux into permissive mode. Rotate the audit log, or just use 'tail -f audit.log > mypol.avcs'. Run through all of the things that need to happen during normal operation. When that's done, you can use mypol.avcs or the rotated audit.log to generate the new policy.
setsebool -P rsync_export_all_ro 1
That's only necessary if you're running rsyncd, which I think you're not.
Rsync fighting SELinux seems to be a common problem lately.
I blogged on this a week or so ago.
http://danwalsh.livejournal.com/61646.html
On 01/28/2013 01:36 AM, Gordon Messmer wrote:
Don't do that. I see something like that frequently given as advice for generating a policy, but it'll only work if rsync is the only thing that's being denied (or something else in an rsync context). From your original email, you're probably seeing at least one denial to ssh in NetworkManager's context.
Generally speaking, it's what the SELinux troubleshooter suggests. And, of course, it's often what's needed. Here, it just revealed that there's another issue with NM.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/28/2013 01:42 PM, Joe Zeff wrote:
On 01/28/2013 01:36 AM, Gordon Messmer wrote:
Don't do that. I see something like that frequently given as advice for generating a policy, but it'll only work if rsync is the only thing that's being denied (or something else in an rsync context). From your original email, you're probably seeing at least one denial to ssh in NetworkManager's context.
Generally speaking, it's what the SELinux troubleshooter suggests. And, of course, it's often what's needed. Here, it just revealed that there's another issue with NM.
It is also recommended that you submit this as a bug so someone more knowledgeable looks at it.
In this case I would like to know what problems you are having with it.
On 01/28/2013 10:42 AM, Joe Zeff wrote:
And, of course, it's often what's needed.
Unless you know that one specific process is affected by the policy, it's pretty much always better to use 'tail -f' to capture all of the AVCs starting at the time that you begin testing in permissive mode than to grep for a specific context.
Here, it just revealed that there's another issue with NM.
No, it didn't. We knew from the beginning that ssh was affected by the policy, and William generated a policy that will only affect rsync. grep didn't reveal anything, it produced a module with too narrow a scope to fix the problem.