[Pkg-sysvinit-devel] Bug#738759: fix for the bug
* Gerfried Fuchs rho...@deb.at [2014-02-14 08:08:14 CET]:
Please find attach a proposed patch for the issue. I hope we can get
around at work to test it properly within the next few days, but from
what I can tell this should be a good approach.
And a patch on top of that. I had the false impression that return is
able to return a string too, but that's not possible with in shell.
Thus the new patch with edit the varible directly inside the function,
which I actually tried to avoid, but that's not really possible within
shell scripts it seems.
Enjoy,
Rhonda
--
Fühlst du dich mutlos, fass endlich Mut, los |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|
From 668707eadf4cb546f782917d57eb7c7c024f51ca Mon Sep 17 00:00:00 2001
From: Gerfried Fuchs rho...@debian.org
Date: Sun, 16 Feb 2014 10:54:52 +0100
Subject: [PATCH 2/2] return in shell scripts only work with numeric values
This fixes the error in the first patch. I would have liked it to not
have to edit the variable within the functions for easier reading, but
unfortunately shell doesn't offer that possibility.
---
debian/src/sysv-rc/etc/init.d/rc | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/debian/src/sysv-rc/etc/init.d/rc b/debian/src/sysv-rc/etc/init.d/rc
index 7767778..9d8024f 100644
--- a/debian/src/sysv-rc/etc/init.d/rc
+++ b/debian/src/sysv-rc/etc/init.d/rc
@@ -128,7 +128,7 @@ esac
kill_test_add() {
script=$1
# Check if the script is there.
- [ ! -f $script ] return
+ [ ! -f $script ] return
#
# Find stop script in previous runlevel but
@@ -142,14 +142,14 @@ kill_test_add() {
# and _no_ start script there, we don't
# have to re-stop the service.
#
- [ -f $previous_stop ] [ ! -f $previous_start ] return
+ [ -f $previous_stop ] [ ! -f $previous_start ] return
# Stop the service.
- return $script
+ SCRIPTS=$SCRIPTS $script
}
start_test_add() {
script=$1
- [ ! -f $script ] return
+ [ ! -f $script ] return
suffix=${script#/etc/rc$runlevel.d/S[0-9][0-9]}
if [ $previous != N ]
@@ -166,7 +166,7 @@ start_test_add() {
# have to re-start the service.
#
if [ start = $ACTION ] ; then
- [ -f $previous_start ] [ ! -f $stop ] return
+ [ -f $previous_start ] [ ! -f $stop ] return
else
# Workaround for the special
# handling of runlevels 0 and 6.
@@ -176,11 +176,11 @@ start_test_add() {
# and _no_ start script there, we don't
# have to re-stop the service.
#
- [ -f $previous_stop ] [ ! -f $previous_start ] return
+ [ -f $previous_stop ] [ ! -f $previous_start ] return
fi
fi
- return $script
+ SCRIPTS=$SCRIPTS $script
}
# Is there an rc directory for this new runlevel?
@@ -221,10 +221,10 @@ then
fi
if [ $level = $CURLEVEL ]
then
-SCRIPTS=$SCRIPTS $(kill_test_add $s)
+kill_test_add $s
continue
fi
- SCRIPTS=$SCRIPTS $(kill_test_add $s)
+ kill_test_add $s
startup stop $SCRIPTS
CURLEVEL=$level
@@ -257,10 +257,10 @@ then
fi
if [ $level = $CURLEVEL ]
then
-SCRIPTS=$SCRIPTS $(start_test_add $s)
+start_test_add $s
continue
fi
- SCRIPTS=$SCRIPTS $(start_test_add $s)
+ start_test_add $s
startup $ACTION $SCRIPTS
CURLEVEL=$level
--
1.8.5.3
___
Pkg-sysvinit-devel mailing list
Pkg-sysvinit-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#738855: [oss-security] Re: Bug#738855: initscripts: Skip killing root-owned process starting with @
On Sat, Feb 15, 2014 at 05:22:15PM +0100, Florian Weimer wrote: * Helmut Grohne: In this context allowing user processes to not be killed merely by changing their name could cause data loss during shutdown by blocking umount. Does that actually work? If so, it's a funcitonality bug that should be fixed. Usually, user processes are killed by sendsigs and that is why they cannot block umount. For instance, if a processes ends up being unkillable (e.g. due to a kernel oops), you can experience data loss (been there, done that). What is new here is that systemd proposed a generic exemption mechanism for processes with effective UID 0. Judging from the responses received so far, I think that the consensus is that effective UID 0 should be considered fully privileged no matter how restricted such a process is. That is a perfectly fine choice (especially in the presence of user namespaces), but we'll have to keep it in mind when looking at other system components that may violate this assumption (e.g. SELinux, Linux capabilities). I conclude that the implementation in systemd is not considered vulnerable. Helmut ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#738855: initscripts: Skip killing root-owned process starting with @
On Fri, Feb 14, 2014 at 09:18:19AM +0100, Helmut Grohne wrote: Hmm. Maybe you can hold this patch off for a little longer? Discussion on oss-sec is inconclusive. Specifically there is no strong opinion that the approach is considered to be a vulnerability or weakness. Please move forward with your patch (barring other reviews). For all participants in this bug, please do *not* Cc oss-sec unless you intend to discuss security aspects. Helmut ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#686895: initscripts: /forcefsck: fsck -f undefined (e2fsck-ism)
tag 686895 + patch thanks Hi, I ran into the very same bug. It seems to be a more conceptual problem than btrfs-related, but for making btrfsck work, I added this patch: --- checkroot.sh2014-02-16 23:34:17.349214647 + +++ /etc/init.d/checkroot.sh2014-02-16 23:42:03.19371 + @@ -187,6 +187,12 @@ if [ -f /forcefsck ] || grep -s -w -i forcefsck /proc/cmdline then force=-f + + # btrfsck doesn't know -f + mount | while read dev on path type fs fnord; do + [ x/ = x$path -a xbtrfs = x$fs ] \ +break + done force= else force= fi It checks if / is a btrfs file system and then removes the -f from the fsck(8) command line. I don't know if it's sensible to add something like a blacklist for file systems whose fsck doesn't know -f at this place. Cheers, Julius ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Processed: initscripts: /forcefsck: fsck -f undefined (e2fsck-ism)
Processing commands for cont...@bugs.debian.org: tag 686895 + patch Bug #686895 [initscripts] initscripts: /forcefsck: fsck -f undefined (e2fsck-ism) Added tag(s) patch. thanks Stopping processing here. Please contact me if you need assistance. -- 686895: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686895 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
