Bug#420637: [Linux-ha-dev] Re: Bug#420637: heartbeat-2: File descriptor leak?
Dejan Muhamedagic wrote:
> Hi,
>
> On Thu, Apr 26, 2007 at 11:14:46AM +0900, Simon Horman wrote:
>> On Tue, Apr 24, 2007 at 09:51:45AM +0900, Simon Horman wrote:
>>> forwarded 420637 [EMAIL PROTECTED]
>>> thanks
>>>
>>> On Mon, Apr 23, 2007 at 07:28:53PM +0200, Erich Schubert wrote:
>>>> Package: heartbeat-2
>>>> Version: 2.0.7-2
>>>> Severity: normal
>>>>
>>>> It seems that heartbeat-2 leaks a file descriptor to it's child
>>>> processes. From the SELinux audit log:
>>>>
>>>> avc: denied { read } for pid=2403 comm="ip" name="heartbeat.pid"
>>>> dev=ida/c0d0p5 ino=86181 scontext=root:system_r:ifconfig_t:s0
>>>> tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=file
>>>>
>>>> avc: denied { read } for pid=3210 comm="rndc" name="heartbeat.pid"
>>>> dev=ida/c0d0p5 ino=86181 scontext=root:system_r:ndc_t:s0
>>>> tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=file
>>>>
>>>> avc: denied { read } for pid=3303 comm="openvpn" name="heartbeat.pid"
>>>> dev=ida/c0d0p5 ino=86181 scontext=root:system_r:openvpn_t:s0
>>>> tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=file
>
> I don't speak SElinux: comm= denotes a program? I suppose that ip
> is from IPaddr2 then. Do you have openvpn and bind in your
> heartbeat config? Perhaps you could also post your heartbeat
> configuration (ha.cf and haresources/cib.xml).
I don't see any pidfile fd leaks in the code. This code handling
pidfiles is in lib/clplumbing/cl_pidfile.c.
I also looked for references to "heartbeat.pid" which appears only in
the #define PIDFILE - from outside the functions in cl_pidfile. I can't
find any.
I could easily believe that there are file descriptor leaks from the
LRM, but I don't know how a file descriptor pointing at "heartbeat.pid"
could have leaked. Do I understand this correctly?
So, I wonder if I understand what's in the logs, I don't see how that
could have come from heartbeat 2.0.7.
Never mind. This was apparently fixed sometime after 2.0.7.
http://hg.linux-ha.org/dev/rev/549c74fc1e33
--
Alan Robertson <[EMAIL PROTECTED]>
"Openness is the foundation and preservative of friendship... Let me
claim from you at all times your undisguised opinions." - William
Wilberforce
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#418210: [Linux-ha-dev] Fwd: Bug#418210: heartbeat-2: /etc/ha.d/authkeys should not determine which nodes are in the cluster
Simon Horman wrote:
> [ Reposting as I sent it to linux-ha-devel instead of
> linux-ha-devel the first time around ]
>
> This seems to be a bit of an easy trap to fall into.
> Are there any fixes floating around? I was thinking
> that perhaps a cluster id of some sort would be a good
> idea. But I'm not sure.
With only one role possible ("cluster member"), the distinction between
authentication and authorization is very small.
With only one role possible, it isn't completely clear what the value of
having someone be authenticated but not authorized. If they aren't
authorized as "cluster member", then they have NO role they can play in
the cluster.
If you're a cluster member, then you're a full peer. If you're not a
cluster member, then you're nobody.
But, what value there is, is implemented by the "node" directive for
those who don't want to use autojoin. If you're authenticated but not
authorized by this mechanism, it's almost certainly an error, so we
print error messages for such communication.
With autojoin enabled, if you're authenticated as cluster member, then
you area also authorized to take the role of "cluster member".
The two only truly need to be separate when there is more than one role
possible.
We don't have more than one possible role for this communication
mechanism - and we won't have from this authentication source.
If you make the mistake described in the email, and you don't change the
host name either, then you're completely screwed - and adding some kind
of authorization mechanism won't help you. Because cloning it onto a
new machine is indistinguishable from restoring it onto replacement
hardware for something broken.
So, you're probably going to change the system name. While you're at
it, turn off heartbeat or fix the configuration.
The moral of the story is, if you're going to be a system administrator,
you need to know how to do some things properly, and how to recover from
them when you screw up. Security mechanisms are NOT designed to keep
admins from screwing up. They're designed to keep bad guys out. If
admins with root privileges are going to screw up, security mechanisms
are not going to make everything happy.
I'd love to avoid this problem in general - if it were easy.
But if the best we can do is raise the overhead of managing the systems,
rewrite the software, and make everything else harder to avoid one case
where the admin screws up, but leave many other cases uncovered, then
I'm not interested. And, I suspect that's the best we can do.
Anyone who has a concrete proposal for how this can be fixed for all
cases correctly without a complete rewrite of the communications layer
is encouraged to suggest it.
Horms might have made the beginnings of such a proposal, but I didn't
understand what he said.
--
Alan Robertson <[EMAIL PROTECTED]>
"Openness is the foundation and preservative of friendship... Let me
claim from you at all times your undisguised opinions." - William
Wilberforce
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#369815: [Linux-ha-dev] Re: Bug#369815: ships binary in /etc
Lars Marowsky-Bree wrote: On 2006-06-08T08:21:38, Alan Robertson <[EMAIL PROTECTED]> wrote: Please fix it everywhere, if you don't mind. Thanks Horms!! Of course, special attention needs to be paid to upgrading to (and possibly, back off from) a version with that change. I'm pretty sure that RPM handles that kind of thing correctly... There may be files in there which aren't owned by our package though, or modified. Huh? I just meant make individual symlinks for a individual binaries. NOT a symlink for the entire directory. -- Alan Robertson <[EMAIL PROTECTED]> "Openness is the foundation and preservative of friendship... Let me claim from you at all times your undisguised opinions." - William Wilberforce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#369815: [Linux-ha-dev] Re: Bug#369815: ships binary in /etc
Lars Marowsky-Bree wrote: On 2006-06-08T07:15:01, Alan Robertson <[EMAIL PROTECTED]> wrote: Unfortunately heartbeat (for fairly broken reasons IMHO) really needs those files there. Could we symlink 'em somewhere? Yes, I think that is a good solution (short of rearanging the resource paths completely). I can do this fairly easily in the Debian packaging and intend to do so shortly. Do you want me to shoe-horn this into the relevant Makefile.am, or just leave it as a Debian thing? Please fix it everywhere, if you don't mind. Thanks Horms!! Of course, special attention needs to be paid to upgrading to (and possibly, back off from) a version with that change. I'm pretty sure that RPM handles that kind of thing correctly... -- Alan Robertson <[EMAIL PROTECTED]> "Openness is the foundation and preservative of friendship... Let me claim from you at all times your undisguised opinions." - William Wilberforce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#369815: [Linux-ha-dev] Re: Bug#369815: ships binary in /etc
Horms wrote:
On Tue, Jun 06, 2006 at 11:01:25PM -0600, Alan Robertson wrote:
Horms wrote:
On Thu, Jun 01, 2006 at 03:24:48PM +0200, Marc 'HE' Brockschmidt wrote:
Package: heartbeat
Severity: serious
Heya,
Let's see what the FHS says:
"No binaries should be located under /etc." [3.4]
Now, what does heartbeat do?
[EMAIL PROTECTED]:/tmp/he$ dpkg-deb -x heartbeat_1.2.4-8_i386.deb bar
[EMAIL PROTECTED]:/tmp/he$ file bar/etc/ha.d/resource.d/IPv6addr
bar/etc/ha.d/resource.d/IPv6addr: ELF 32-bit LSB executable, Intel 80386,
version 1 (SYSV), for GNU/Linux 2.4.1, dynamically linked (uses shared
libs), for GNU/Linux 2.4.1, stripped
Unfortunately heartbeat (for fairly broken reasons IMHO) really
needs those files there.
Could we symlink 'em somewhere?
Yes, I think that is a good solution (short of rearanging the
resource paths completely). I can do this fairly easily in the Debian
packaging and intend to do so shortly. Do you want me to shoe-horn this
into the relevant Makefile.am, or just leave it as a Debian thing?
Please fix it everywhere, if you don't mind.
Thanks Horms!!
--
Alan Robertson <[EMAIL PROTECTED]>
"Openness is the foundation and preservative of friendship... Let me
claim from you at all times your undisguised opinions." - William
Wilberforce
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#369815: [Linux-ha-dev] Re: Bug#369815: ships binary in /etc
Horms wrote: On Thu, Jun 01, 2006 at 03:24:48PM +0200, Marc 'HE' Brockschmidt wrote: Package: heartbeat Severity: serious Heya, Let's see what the FHS says: "No binaries should be located under /etc." [3.4] Now, what does heartbeat do? [EMAIL PROTECTED]:/tmp/he$ dpkg-deb -x heartbeat_1.2.4-8_i386.deb bar [EMAIL PROTECTED]:/tmp/he$ file bar/etc/ha.d/resource.d/IPv6addr bar/etc/ha.d/resource.d/IPv6addr: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.4.1, dynamically linked (uses shared libs), for GNU/Linux 2.4.1, stripped Unfortunately heartbeat (for fairly broken reasons IMHO) really needs those files there. Could we symlink 'em somewhere? -- Alan Robertson <[EMAIL PROTECTED]> "Openness is the foundation and preservative of friendship... Let me claim from you at all times your undisguised opinions." - William Wilberforce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
