linux-kernel - Re: Linux 2.6.32-rc3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200910151751.02622.elendil@planet.nl>
Date:	Thu, 15 Oct 2009 17:51:01 +0200
From:	Frans Pop <elendil@...net.nl>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	torvalds@...ux-foundation.org, hohndel@...radead.org,
	lenb@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: Linux 2.6.32-rc3

Ingo Molnar wrote:
> hm, i think you ignored (or missed, or found irrelevant) my first
> suggested variant:
> 
> v2.6.31
> v2.6.31+

A general concern about adding the "+".

Anyone want to bet how many (init?) scripts there are in userspace that do 
something like:

KVERS="$(uname -r | cut -d"-" -f1)"
case $KVERS in
  2.6.*)
    minor=$(echo $KVERS | cut -d"." -f3)
    if [ $minor -lt 10 ]; then
      # do something
    fi ;;
esac

Note that the '[ $minor -lt 10 ]' will now produce an error because
'31+' is no longer a valid number:
   bash: [: 31+: integer expression expected

A "-" has for ages been the standard separator between the kernel version 
and any suffixes, certainly in Debian. Loads of scripts will assume that.

In an earlier mail I said that I would consider using the "+". This is 
seriously making me have second thoughts, even for custom built kernels.

Here are some real life examples from my Debian stable system:
/etc/init.d/pcmciautils:
supported_kernel()
{
    case $KERNEL_VERSION in
        2.[012345].*|2.6.[0-9]|2.6.[0-9][!0-9]*) return 1 ;;
        2.6.1[012]|2.6.1[012][!0-9]*) return 1 ;;
    esac
    return 0
}

Would have failed for e.g. a 2.6.12+ kernel.

/etc/init.d/umountnfs.sh:
KERNEL="$(uname -s)"
RELEASE="$(uname -r)"
case "${KERNEL}:${RELEASE}" in
  Linux:[01].*|Linux:2.[01].*)
        FLAGS=""
        ;;
  Linux:2.[23].*|Linux:2.4.?|Linux:2.4.?-*|Linux:2.4.10|Linux:2.4.10-*)
        FLAGS="-f"
        ;;
  *)
        FLAGS="-f -l"
        ;;
esac

Would have failed for e.g. a 2.4.7+ kernel.

Sure, these won't fail if we start adding the "+" now, but will the people 
writing such tests in the future always remember to allow for the "+", 
especially given that it will be relatively rare in a distro context?

Cheers,
FJP
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/