Re: [Linux-ha-dev] Fwd: [Debian-ha-maintainers] Bug#598549: cluster-agents: CVE-2010-3389: insecure library loading
On Fri, Oct 15, 2010 at 01:15:51PM -0400, Michael Smith wrote: > Lars Ellenberg wrote: > > BTW, looking at those ocf-shellfuncs, did anyone notice that > > ocf_take_lock is broken, because it's racy? > > Not sure if/how we should solve that, though. > > ln is atomic so this ought to work: > > local tmp > tmp=$(mktemp "$lockfile.XX") > echo "$$" > "$tmp" > > while : > do > if ! ocf_pidfile_status "$lockfile" > then > ln "$tmp" "$lockfile" 2>/dev/null && break > fi > ocf_log info "Sleeping until $lockfile is released..." You cannot rely on the lockfile to be removed, the other one may die without cleaning up after himself. And if you remove it yourself (once you detected it is stale), you open an other racy window... > sleep 0.$rnd > done > > > possibly this could do it? > > while :; do > > pid=$(head -n1 $file) > > [ x$pid = x$$ ] && return 0 # won the race > > if [ -z "$pid" ] || ! kill -0 $pid ; then > > echo $$ > $file > > else > > # other still running > > sleep 1 > > fi > > done > > Looks like that would work, too. -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Fwd: [Debian-ha-maintainers] Bug#598549: cluster-agents: CVE-2010-3389: insecure library loading
Lars Ellenberg wrote: > BTW, looking at those ocf-shellfuncs, did anyone notice that > ocf_take_lock is broken, because it's racy? > Not sure if/how we should solve that, though. ln is atomic so this ought to work: local tmp tmp=$(mktemp "$lockfile.XX") echo "$$" > "$tmp" while : do if ! ocf_pidfile_status "$lockfile" then ln "$tmp" "$lockfile" 2>/dev/null && break fi ocf_log info "Sleeping until $lockfile is released..." sleep 0.$rnd done > possibly this could do it? > while :; do > pid=$(head -n1 $file) > [ x$pid = x$$ ] && return 0 # won the race > if [ -z "$pid" ] || ! kill -0 $pid ; then > echo $$ > $file > else > # other still running > sleep 1 > fi > done Looks like that would work, too. Mike ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Fwd: [Debian-ha-maintainers] Bug#598549: cluster-agents: CVE-2010-3389: insecure library loading
On Wed, Oct 06, 2010 at 11:50:40AM +0200, Dejan Muhamedagic wrote:
> On Tue, Oct 05, 2010 at 07:34:31PM +0200, Lars Ellenberg wrote:
> > On Tue, Oct 05, 2010 at 04:03:47PM +0200, Dejan Muhamedagic wrote:
> > > > So it is run periodically by root (well, the lrmd, as root).
> > > > Even though the cwd of lrmd should be ok, permission wise, in case the
> > > > script does cd into somewhere (I don't think it does, now) where someone
> > > > with lesser privilege was able to place some evil *.so, the next command
> > > > executed by the script may do interesting things.
> > >
> > > I really doubt that, though it looks dangerous, there is a way to
> > > exploit this without root access.
> >
> > You never know.
> > The script itself may not, but it starts something else,
> > which may cd somewhere else, then fork/exec.
[ ... some suggestions how to fix it ... ]
> Great. Can you please apply this to the repo.
I think I have something simpler/better, even.
RFC below, if there are no objections, it will go in next week.
Someone please double check the "local IFS=:" part, maybe on some SAP
systems /bin/sh is something that does not handle that correctly?
BTW, looking at those ocf-shellfuncs, did anyone notice that
ocf_take_lock is broken, because it's racy?
Not sure if/how we should solve that, though.
possibly this could do it?
while :; do
pid=$(head -n1 $file)
[ x$pid = x$$ ] && return 0 # won the race
if [ -z "$pid" ] || ! kill -0 $pid ; then
echo $$ > $file
else
# other still running
sleep 1
fi
done
And, how about adding HUP/TERM/INT to the EXIT for the trap in
ocf_release_lock_on_exit?
Oh, and did you know that $lockfile better be an absolute path,
or you'll end up deleting something unexpected (or nothing at
all) if you cd to somewhere in the script later.
BTW2, why is "ocf_is_true ja" a true value,
but "ocf_is_true oui" is not?
Because lmb lives in Hamburg, not Paris? ;-)
# HG changeset patch
# User Lars Ellenberg
# Date 1287158610 -7200
# Node ID dc12cb9f7370a3cc9ecfe5d1a26da9e002a90341
# Parent 6efae155209ed2cba851d8c64a796f24ce84fd91
Low: SAPDatabase,SAPInstance: beautify LD_LIBRARY_PATH processing
relates to 2773e5850003 and bnc#640026
diff -r 6efae155209e -r dc12cb9f7370 heartbeat/.ocf-shellfuncs.in
--- a/heartbeat/.ocf-shellfuncs.in Thu Oct 14 18:39:07 2010 +0900
+++ b/heartbeat/.ocf-shellfuncs.in Fri Oct 15 18:03:30 2010 +0200
@@ -429,6 +429,26 @@
[ ! -z "${OCF_RESKEY_CRM_meta_master_max}" ] && [
"${OCF_RESKEY_CRM_meta_master_max}" -gt 0 ]
}
+# Takes one parameter (additional parameters ignored),
+# and prepends it to LD_LIBRARY_PATH.
+# If it's already there, don't add it again,
+# but make it the first component.
+# Also make sure we don't create an empty LD_LIBRARY_PATH component
+# (trailing or leading colon, or "double colon"),
+# as that is considered a security issue.
+ocf_prepend_ld_library_path()
+{
+ local x p=$1
+ local IFS=:
+ for x in $LD_LIBRARY_PATH ; do
+ [ "x$x" = "x$1" ] && continue
+ [ "x$x" = "x" ] && continue
+ p=$p:$x
+ done
+ LD_LIBRARY_PATH=$p
+ export LD_LIBRARY_PATH
+}
+
# usage: dirname DIR
dirname()
{
diff -r 6efae155209e -r dc12cb9f7370 heartbeat/SAPDatabase
--- a/heartbeat/SAPDatabase Thu Oct 14 18:39:07 2010 +0900
+++ b/heartbeat/SAPDatabase Fri Oct 15 18:03:30 2010 +0200
@@ -965,11 +965,10 @@
esac
fi
-# as root user we need the library path to the SAP kernel to be able to call
executables
-if [ `echo $LD_LIBRARY_PATH | grep -c "^$DIR_EXECUTABLE\>"` -eq 0 ]; then
- LD_LIBRARY_PATH=$DIR_EXECUTABLE${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH
- export LD_LIBRARY_PATH
-fi
+# As root user we need the library path to the SAP kernel
+# to be able to call executables.
+ocf_prepend_ld_library_path "$DIR_EXECUTABLE"
+
sidadm="`echo $SID | tr [:upper:] [:lower:]`adm"
# What kind of method was invoked?
diff -r 6efae155209e -r dc12cb9f7370 heartbeat/SAPInstance
--- a/heartbeat/SAPInstance Thu Oct 14 18:39:07 2010 +0900
+++ b/heartbeat/SAPInstance Fri Oct 15 18:03:30 2010 +0200
@@ -296,10 +296,7 @@
fi
# as root user we need the library path to the SAP kernel to be able to call
sapcontrol
- if [ `echo $LD_LIBRARY_PATH | grep -c "^$DIR_EXECUTABLE\>"` -eq 0 ]; then
-LD_LIBRARY_PATH=$DIR_EXECUTABLE${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH
-export LD_LIBRARY_PATH
- fi
+ ocf_prepend_ld_library_path "$DIR_EXECUTABLE"
sidadm="`echo $SID | tr [:upper:] [:lower:]`adm"
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
___
Re: [Linux-ha-dev] Next release from Linux-HA? (was: [PATCH] IPv6addr: removing libnet dependency)
On Fri, Oct 15, 2010 at 07:18:02PM +0900, Keisuke MORI wrote: > Hi Lars, > > We have talked about the next release of heartbeat/resource-agents > packages while ago. > As Pacemaker-1.0.10 is about to release soon, I think it's good time > to release those packages now too for the best use of Pacemaker. > > I think that heartbeat-3.0.4 / resource-agents-1.0.4 should be > released at least because it has already been 6 months since the last > release. > > How do you think about it and when can we release the packages? Dejan and I happen to sit in the same office from time to time, and yes, we are working on that. There will be a few CTS runs with pacemaker 1.0 and 1.1 on heartbeat, I think we will release 3.0.4, agents and glue within the next two weeks. -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
[Linux-ha-dev] New stateful RA: conntrackd
Hi everybody,
I wrote a master/slave RA to manage conntrackd, the connection tracking
daemon from the netfilter project. Conntrackd is used to replicate
connection state between highly available stateful firewalls.
Conntrackd replicates data using multicast. Basically it sends state
information about connections written to its kernels connection tracking
table. Replication slaves write these updates to an external cache.
When a firewall is to take over the master role, it commits the external
cache to the kernel and so "knows" the connections that were previously
running through the old master system and clients can continue working
without having to open a new connection.
While there has been an RA for conntrackd (at least I found something
that looked like it in a pastebin using google), this one was not able
to deal with failback, which is a thing I needed, and was not yet
included in the repository. I hope this one will be included.
The main challenge in this RA was the failback part. Say one system goes
down completely. Then it loses the kernel connection tracking table and
the external cache. Once it comes back, it will receive updates for new
connections that are initiated through the master, but it will neither
be sent the complete tracking table of the current master, nor can it
request this (that's how I understand and tested conntrackd works,
please correct me if I'm wrong :)).
This may be acceptable for short-lived connections and configurations
where there is no preferred master system, but it does become a problem
if you have either of those.
So my approach is to send a so called "bulk update" in two situations:
a) in the notify pre promote call, if the local machine is not the
machine to be promoted
This part is responsible for sending the update to a preferred master
that had previously failed (failback).
b) in the notify post start call, if the local machine is the master
This part is responsible for sending the update to a previously failed
machine that re-joins the cluster but is not to be promoted right away.
For now I limited the RA to deal with only 2 clones and 1 master since
this is the only testbed I have and I am not 100% sure what happens to
the new master in situation a) if there are multiple slaves.
Configuration could look like this, notify=true is important:
primitive conntrackd ocf:intelegence:conntrackd \
op monitor interval="10" timeout="10" \
op monitor interval="11" role="Master" timeout="10"
primitive ip-extern ocf:heartbeat:IPaddr2 \
params ip="10.2.50.237" cidr_netmask="24" \
op monitor interval="10" timeout="10"
primitive ip-intern ocf:heartbeat:IPaddr2 \
params ip="10.2.52.3" cidr_netmask="24" \
op monitor interval="10" timeout="10"
ms ms-conntrackd conntrackd \
meta target-role="Started" globally-unique="false" notify="true"
colocation ip-intern-extern inf: ip-extern ip-intern
colocation ips-on-conntrackd-master inf: ip-intern ms-conntrackd:Master
order ips-after-conntrackd inf: ms-conntrackd:promote ip-intern:start
Please review and test the RA, post comments and questions. Maybe it can
be included in the repository.
Regards
Dominik
ps. yes, some parts are from linbit's drbd RA and some parts may also be
from Andrew's Stateful RA. Hope that's okay.
--
IN-telegence GmbH
Oskar-Jäger-Str. 125
50825 Köln
Registergericht AG Köln - HRB 34038
USt-ID DE210882245
Geschäftsführende Gesellschafter: Christian Plätke und Holger Jansen
#!/bin/bash
#
#
# An OCF RA for conntrackd
# http://conntrack-tools.netfilter.org/
#
# Copyright (c) 2010 Dominik Klein
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of version 2 of the GNU General Public License as
# published by the Free Software Foundation.
#
# This program is distributed in the hope that it would be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
#
# Further, this software is distributed without any warranty that it is
# free of the rightful claim of any third person regarding infringement
# or the like. Any license provided herein, whether implied or
# otherwise, applies only to this software file. Patent licenses, if
# any, provided herein do not apply to combinations of this program with
# other software, or any other product whatsoever.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write the Free Software Foundation,
# Inc., 59 Temple Place - Suite 330, Boston MA 02111-1307, USA.
#
###
# Initialization:
. ${OCF_ROOT}/resource.d/heartbeat/.ocf-shellfuncs
export LANG=C LANGUAGE=C LC_ALL=C
meta_data() {
cat <
1.1
Master/Slave OCF Resource Agent for conntrackd
This resource agent manages conntrackd
Full path to conntrackd executable
Full path to conntrackd executable
Re: [Linux-ha-dev] Next release from Linux-HA? (was: [PATCH] IPv6addr: removing libnet dependency)
On 15.10.2010 13:39, Dejan Muhamedagic wrote: > Hi, > > On Fri, Oct 15, 2010 at 01:09:14PM +0200, Florian Haas wrote: >> On 2010-10-15 12:18, Keisuke MORI wrote: >>> Hi Lars, >>> >>> We have talked about the next release of heartbeat/resource-agents >>> packages while ago. >>> As Pacemaker-1.0.10 is about to release soon, I think it's good time >>> to release those packages now too for the best use of Pacemaker. >>> >>> I think that heartbeat-3.0.4 / resource-agents-1.0.4 should be >>> released at least because it has already been 6 months since the last >>> release. >> >> I fully agree. I believe Heartbeat is pretty much good to go (Lars hsa >> the latest details). For resource-agents and cluster-glue we might wait >> until November, just in case some issues are better resolved in-person >> at Plumbers. > > Are there any issues in particular? In the next week I will implement yours suggestion regarding mysql RA (especially using crm_attribute instead of state file). So will be great if it can be in next release. -- Best regards, Marek Marczykowski | gg:2873965 | RLU #390519 marmarek at staszic waw pl | xmpp:marmarek at staszic waw pl smime.p7s Description: S/MIME Cryptographic Signature ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Next release from Linux-HA? (was: [PATCH] IPv6addr: removing libnet dependency)
Hi, On Fri, Oct 15, 2010 at 01:09:14PM +0200, Florian Haas wrote: > On 2010-10-15 12:18, Keisuke MORI wrote: > > Hi Lars, > > > > We have talked about the next release of heartbeat/resource-agents > > packages while ago. > > As Pacemaker-1.0.10 is about to release soon, I think it's good time > > to release those packages now too for the best use of Pacemaker. > > > > I think that heartbeat-3.0.4 / resource-agents-1.0.4 should be > > released at least because it has already been 6 months since the last > > release. > > I fully agree. I believe Heartbeat is pretty much good to go (Lars hsa > the latest details). For resource-agents and cluster-glue we might wait > until November, just in case some issues are better resolved in-person > at Plumbers. Are there any issues in particular? > What do others think? I'm not sure if we need to wait for the conference. As Keisuke-san said, resource-agents are overdue and cluster-glue has some important fixes in the meantime. Cheers, Dejan > Cheers, > Florian > > ___ > Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev > Home Page: http://linux-ha.org/ ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Next release from Linux-HA? (was: [PATCH] IPv6addr: removing libnet dependency)
On 2010-10-15 12:18, Keisuke MORI wrote: > Hi Lars, > > We have talked about the next release of heartbeat/resource-agents > packages while ago. > As Pacemaker-1.0.10 is about to release soon, I think it's good time > to release those packages now too for the best use of Pacemaker. > > I think that heartbeat-3.0.4 / resource-agents-1.0.4 should be > released at least because it has already been 6 months since the last > release. I fully agree. I believe Heartbeat is pretty much good to go (Lars hsa the latest details). For resource-agents and cluster-glue we might wait until November, just in case some issues are better resolved in-person at Plumbers. What do others think? Cheers, Florian signature.asc Description: OpenPGP digital signature ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
[Linux-ha-dev] Next release from Linux-HA? (was: [PATCH] IPv6addr: removing libnet dependency)
Hi Lars, We have talked about the next release of heartbeat/resource-agents packages while ago. As Pacemaker-1.0.10 is about to release soon, I think it's good time to release those packages now too for the best use of Pacemaker. I think that heartbeat-3.0.4 / resource-agents-1.0.4 should be released at least because it has already been 6 months since the last release. How do you think about it and when can we release the packages? Regards, Keisuke MORI 2010/7/27 Lars Ellenberg : > On Tue, Jul 27, 2010 at 04:12:34PM +0900, Keisuke MORI wrote: >> 2010/7/27 Keisuke MORI : >> > 2010/7/26 Lars Ellenberg : >> >> On Mon, Jul 26, 2010 at 06:39:50PM +0900, Keisuke MORI wrote: >> >> Heartbeat does not have many changes (appart from some cleanup in the >> >> build dependencies), so there is no urge to release a 3.0.4, but we >> >> could do so any time. >> (...) >> > For heartbeat, I personally like "pacemaker on" in ha.cf :) >> >> >> I should have mentioned this too, the version number in the log file >> from heartbeat 3.0.3 seems incorrect. I want to fix this soon to avoid >> confusion. >> >> >> Jul 20 14:08:50 srv01 heartbeat: [6299]: info: Configuration >> validated. Starting heartbeat 3.0.2 > > Yes, I know. Not a problem. > Needs to be changed in configure.ac before the 3.0.4 release. > > -- > : Lars Ellenberg > : LINBIT | Your Way to High Availability > : DRBD/HA support and consulting http://www.linbit.com > > DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. > ___ > Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev > Home Page: http://linux-ha.org/ > -- Keisuke MORI ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
