Re: Bug#459403: libuuid1: missing depends on non-essential package passwd - Debian

This is a discussion on Re: Bug#459403: libuuid1: missing depends on non-essential package passwd - Debian ; On Sun, Jan 06, 2008 at 10:37:03AM +0100, Julien Cristau wrote: > > the libuuid1 postinst contains: > groupadd -f -K GID_MIN=1 -K GID_MAX=999 libuuid > if ! grep -q libuuid /etc/passwd; then > useradd -d /var/lib/libuuid -K UID_MIN=1 -K ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: Re: Bug#459403: libuuid1: missing depends on non-essential package passwd

  1. Re: Bug#459403: libuuid1: missing depends on non-essential package passwd

    On Sun, Jan 06, 2008 at 10:37:03AM +0100, Julien Cristau wrote:
    >
    > the libuuid1 postinst contains:
    > groupadd -f -K GID_MIN=1 -K GID_MAX=999 libuuid
    > if ! grep -q libuuid /etc/passwd; then
    > useradd -d /var/lib/libuuid -K UID_MIN=1 -K UID_MAX=499 -g libuuid libuuid
    > fi
    > mkdir -p /var/lib/libuuid
    > chown libuuid:libuuid /var/lib/libuuid
    > chmod 2775 /var/lib/libuuid
    >
    > The groupadd and useradd commands come from passwd, which is not
    > Essential: yes, so a Depends is needed.
    >
    > Moreover, the postinst succeeds even if any of these commands fail,
    > because 'set -e' is missing at the top of the script.


    So e2fsprogs which is "Essential: yes" depends on libuuid1, so
    libuuid1 is effectively "Essential: yes", right? So if I add a
    dependency on passwd, it will effectively make passwd "Essential:
    yes", as well, and according to policy I should bring it up for
    comment on debian-policy. So, I am doing so now. Any objections if I
    add a dependency on passwd for libuuid1? The aternative would be to
    roll-my-own useradd/adduser functionality, but that would be a real
    PITA....

    Thanks, regards,

    - Ted


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  2. Re: Bug#459403: libuuid1: missing depends on non-essential package passwd

    On Mon, Jan 07, 2008 at 03:23:23AM -0500, Theodore Tso wrote:
    > On Sun, Jan 06, 2008 at 10:37:03AM +0100, Julien Cristau wrote:


    > So e2fsprogs which is "Essential: yes" depends on libuuid1, so
    > libuuid1 is effectively "Essential: yes", right? So if I add a
    > dependency on passwd, it will effectively make passwd "Essential:
    > yes", as well, and according to policy I should bring it up for
    > comment on debian-policy. So, I am doing so now.


    My mail headers disagree. Is this really meant to be on debian-policy
    rather than debian-devel?

    > Any objections if I add a dependency on passwd for libuuid1? The
    > aternative would be to roll-my-own useradd/adduser functionality, but that
    > would be a real PITA....


    I think rolling your own would be wrong no matter what. If there are
    specific reasons why libuuid1 can't depend on passwd, we should address
    those instead.

    But let's have a look:

    Package: passwd
    Version: 1:4.0.18.2-1
    Depends: libc6 (>= 2.6.1-1), libpam0g (>= 0.99.7.1), libselinux1 (>= 2.0.15), login (>= 970502-1), libpam-modules (>= 0.72-5), debianutils (>= 2.15.2)

    $ grep-dctrl -n -FEssential yes -sPre-Depends /var/lib/apt/lists/*sid*Packages \
    | tr ',' '\n' |sed -e's/^ //' | sort -u

    coreutils (>= 5.93-1)
    e2fslibs (= 1.40.3-1)
    initscripts
    libacl1 (>= 2.2.11-1)
    libblkid1 (>= 1.34-1)
    libc6 (>= 2.3.6-6)
    libc6 (>= 2.5)
    libc6 (>= 2.6-1)
    libc6 (>= 2.6.1-1)
    libc6 (>= 2.7-1)
    libcomerr2 (>= 1.34-1)
    libncurses5 (>= 5.4-5)
    libncurses5 (>= 5.6+20071006-3)
    libpam0g (>= 0.99.7.1)
    libpam-runtime (>= 0.76-14)
    libselinux1 (>= 2.0.15)
    libslang2 (>= 2.0.7-1)
    libss2 (>= 1.34-1)
    libuuid1
    libuuid1 (>= 1.34-1)
    sysvinit-utils
    sysv-rc (>= 2.86.ds1-1.2) | file-rc (>> 0.7.0)
    zlib1g (>= 1:1.2.3.3.dfsg-1)
    $

    So libc6, libpam0g, and libselinux1 are already Pre-Depends of some
    essential package or other, and don't pose a problem here.

    login is also Essential: yes, so is only in the list because it's a
    versioned dep; but it's a versioned dep on a version older than oldstable,
    so we can probably prune that dep from passwd to make the essential set just
    a little less tangled. Anyway, nothing in essential currently depends on
    passwd so we know there's no problematic loop here.

    debianutils is likewise essential, and the versioned dep is likewise
    satisfied by the version in stable (though not in oldstable). Again the dep
    could probably be pruned.

    That leaves libpam-modules being pulled in, which is not currently essential
    or a pre-dep of any other essential packages. This is not a spurious
    dependency on the part of passwd; actually, I'm left wondering why login has
    it as a Depends instead of as a Pre-Depends, since the stock login PAM
    config isn't going to work very well without those modules, so login seems
    to be failing the requirement to be minimally functional while unpacked but
    not configured.

    But anyway, let's have a look at what promoting libpam-modules entails.

    Package: libpam-modules
    Version: 0.99.7.1-5
    Depends: libc6 (>= 2.6.1-1), libdb4.6, libpam0g (>= 0.99.7.1), libselinux1 (>= 2.0.15)

    Three familiar libraries again, along with libdb4.6. libdb4.6 itself has no
    dependencies other than libc6.

    So promoting passwd to a Pre-Depends of an Essential package doesn't
    introduce any pre-dependency loops, and the only new packages pulled into
    the transitively-Essential set are ones that arguably are supposed to be
    there already.

    As long as none of the maintainers of other Essential packages have plans to
    introduce a dependency on libuuid1 that would turn this into a loop, this
    looks ok to me.

    (BTW, does anyone want to write an essential-checker to check for those
    loops automatically?

    Cheers,
    --
    Steve Langasek Give me a lever long enough and a Free OS
    Debian Developer to set it on, and I can move the world.
    Ubuntu Developer http://www.debian.org/
    slangasek@ubuntu.com vorlon@debian.org


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  3. Re: Bug#459403: libuuid1: missing depends on non-essential package passwd

    On Mon, Jan 07, 2008 at 03:23:23AM -0500, Theodore Tso wrote:
    > So, I am doing so now. Any objections if I
    > add a dependency on passwd for libuuid1? The aternative would be to
    > roll-my-own useradd/adduser functionality, but that would be a real
    > PITA....


    There are several other possibilities:
    - Move the user creation. It is necessary for uuid-runtime (uuidd), not
    libuuid.
    - Drop e2fsprogs from essential. The only critical part, aka non ext2/3
    specific, it provides is /sbin/fsck IMHO.

    What is the reason for this deamon anyway? It linearises the requests
    and limits the amount of available uuids.

    Bastian

    --
    "We have the right to survive!"
    "Not by killing others."
    -- Deela and Kirk, "Wink of An Eye", stardate 5710.5


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  4. Re: Bug#459403: libuuid1: missing depends on non-essential package passwd

    On Mon, Jan 07, 2008 at 01:16:59AM -0800, Steve Langasek wrote:
    > On Mon, Jan 07, 2008 at 03:23:23AM -0500, Theodore Tso wrote:
    > > On Sun, Jan 06, 2008 at 10:37:03AM +0100, Julien Cristau wrote:

    >
    > > So e2fsprogs which is "Essential: yes" depends on libuuid1, so
    > > libuuid1 is effectively "Essential: yes", right? So if I add a
    > > dependency on passwd, it will effectively make passwd "Essential:
    > > yes", as well, and according to policy I should bring it up for
    > > comment on debian-policy. So, I am doing so now.

    >
    > My mail headers disagree. Is this really meant to be on debian-policy
    > rather than debian-devel?
    >
    > > Any objections if I add a dependency on passwd for libuuid1? The
    > > aternative would be to roll-my-own useradd/adduser functionality, but that
    > > would be a real PITA....


    AFAICS libuuid1 just needs groupadd/useradd to create a user and group
    'libuuid'.

    Since libuuid1 is essential, every system will end up with a libuuid
    user/group, so why not just add it to base-passwd instead of creating it
    dynamically ?

    Cheers,
    --
    Bill.

    Imagine a large red swirl here.


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  5. Re: Bug#459403: libuuid1: missing depends on non-essential package passwd

    On Mon, Jan 07, 2008 at 03:23:23AM -0500, Theodore Tso wrote:
    >
    > So e2fsprogs which is "Essential: yes" depends on libuuid1, so
    > libuuid1 is effectively "Essential: yes", right? So if I add a
    > dependency on passwd, it will effectively make passwd "Essential:
    > yes", as well


    It's not because an essential package Depends on something that that
    should also be set to essential. The clasical example is libc6. Alot
    of the essential package Depend on it but libc6 is not, and should not,
    be essential itself.

    But I think that packages which are essential that need a user/group
    should get a static one in base-passwd which is essential.


    Kurt


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  6. Re: Bug#459403: libuuid1: missing depends on non-essential package passwd

    Bastian Blank wrote:
    > On Mon, Jan 07, 2008 at 03:23:23AM -0500, Theodore Tso wrote:
    >> So, I am doing so now. Any objections if I
    >> add a dependency on passwd for libuuid1? The aternative would be to
    >> roll-my-own useradd/adduser functionality, but that would be a real
    >> PITA....

    >
    > There are several other possibilities:
    > - Move the user creation. It is necessary for uuid-runtime (uuidd), not
    > libuuid.


    Actually the user is created twice currently: in libuuid1.postinst and
    uuid-runtime.postinst.

    Ted, could you please eloborate why you need the useradd in
    libuuid1.postinst at all?

    Cheers,
    Michael
    --
    Why is it that all of the instruments seeking intelligent life in the
    universe are pointed away from Earth?


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFHgoheh7PER70FhVQRAkDUAJ9wP3OfZDnFARUIGQxv9k eLQRNWgQCeKF0W
    olLeom/a01bekJgAoBYeHZ0=
    =GlAn
    -----END PGP SIGNATURE-----


  7. Re: Bug#459403: libuuid1: missing depends on non-essential package passwd

    On Mon, Jan 07, 2008 at 11:34:07AM +0100, Bastian Blank wrote:
    > On Mon, Jan 07, 2008 at 03:23:23AM -0500, Theodore Tso wrote:
    > > So, I am doing so now. Any objections if I
    > > add a dependency on passwd for libuuid1? The aternative would be to
    > > roll-my-own useradd/adduser functionality, but that would be a real
    > > PITA....

    >
    > There are several other possibilities:
    > - Move the user creation. It is necessary for uuid-runtime (uuidd), not
    > libuuid.


    It's actually needed in libuuid, because one of the modes how it can be
    used is a program can be setgid libuuid. If so, then when it calls
    libuuid, it can optionally save the clock sequence number in
    /var/lib/libuuid, and to detect circumstances when the clock goes
    backwards. This guarantees that uniqueness, and makes the UUID
    generation compliant with RFC 4122. Without libuuid being setgid, or
    without the uuidd package installed, the time-based UUID will
    *probably* be unique, but if the time gets reset, and you get
    very. Very unlucky, or if you have multiple SMP threads generating
    huge numbers of time-based UUID's, you could generate duplicate
    UUID's.

    > What is the reason for this deamon anyway? It linearises the requests
    > and limits the amount of available uuids.


    So there are some programs that like to use time-based UUID's because
    they tend to sort much better (particularly if you byte-reverse the
    UUID) when they are used as keys in a database. One such program
    generates a *huge* number of them while initializing its application
    database. It does so in multiple threads and multiple processes
    running in parallel, and it was running into problems because it could
    end up generating duplicate UUID's.

    The uuidd linearises the requests, yes, but in a very clever way where
    each particular thread can request a block of UUID's (with contiguous
    times) so it actually allows a much, MUCH larger number of UUID's to
    be generated, with *significantly* less CPU overhead. I know of only
    one application program that generates this many UUID's (as in tens of
    thousands per second). Unless you use this application, it's
    relatively unlikely that you need it; however, it is a matter of
    correctness as well --- if you want to guarantee uniqueness on an SMP
    system, and guarantee uniqueness in the face of an unreliable clock
    that might go backwards, implementing the requirements of RFC 4122,
    it's necessary. By default though most applications use random
    UUID's, for which none of this rigamarole is necessary.

    So without uuidd installed, the amount of time to generate 100,000
    UUID's is 3.2 seconds. With uuidd installed, the amount of time to
    generate 100,000 UUID's drops down to 0.091 seconds.

    - Ted


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  8. Re: Bug#459403: libuuid1: missing depends on non-essential package passwd

    On Mon, Jan 07, 2008 at 12:39:30PM +0100, Bill Allombert wrote:
    > Since libuuid1 is essential, every system will end up with a libuuid
    > user/group, so why not just add it to base-passwd instead of creating it
    > dynamically ?


    In general I want to avoid almost all further creation of global static
    IDs. The last exception I made was when the installer needed a group
    with a static ID to exist so that it could hardcode its GID in
    /etc/fstab. Global static IDs are difficult to maintain, complicate
    partial upgrades, require user interaction (this should be overhauled,
    admittedly, but nevertheless), and have a very limited available space.

    I don't think "but we don't want to make adduser Priority: required" is
    a good enough reason to add global static IDs; and passwd doesn't need
    to be made Essential just because an Essential package depends on it
    (Essential isn't closed under dependency).

    Cheers,

    --
    Colin Watson [cjwatson@debian.org]


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  9. Re: Bug#459403: libuuid1: missing depends on non-essential package passwd

    Hi,

    I've made some cleanup of the passwd and login dependencies, and
    remembered this discussion.

    The main change is the move of libpam-modules from Depends to Pre-Depends
    for login (which is Essential).
    This moves libpam-modules to a virtual Essential package, which is the
    reason of this mail (but as mentioned in the earlier thread, I don't think
    this may be an issue).

    On Mon, Jan 07, 2008 at 01:16:59AM -0800, Steve Langasek wrote:
    > But let's have a look:
    >
    > Package: passwd
    > Version: 1:4.0.18.2-1
    > Depends: libc6 (>= 2.6.1-1), libpam0g (>= 0.99.7.1), libselinux1 (>= 2.0.15), login (>= 970502-1), libpam-modules (>= 0.72-5), debianutils (>= 2.15.2)

    [...]
    > login is also Essential: yes, so is only in the list because it's a
    > versioned dep; but it's a versioned dep on a version older than oldstable,
    > so we can probably prune that dep from passwd to make the essential set just
    > a little less tangled. Anyway, nothing in essential currently depends on
    > passwd so we know there's no problematic loop here.


    I've removed the versioned dependency of passwd on login (and hence the
    dependency)

    > debianutils is likewise essential, and the versioned dep is likewise
    > satisfied by the version in stable (though not in oldstable). Again the dep
    > could probably be pruned.


    I've kept this one.

    > That leaves libpam-modules being pulled in, which is not currently essential
    > or a pre-dep of any other essential packages. This is not a spurious
    > dependency on the part of passwd; actually, I'm left wondering why login has
    > it as a Depends instead of as a Pre-Depends, since the stock login PAM
    > config isn't going to work very well without those modules, so login seems
    > to be failing the requirement to be minimally functional while unpacked but
    > not configured.


    I've moved the login's dependency on libpam-modules to a Pre-Depends.
    Without libpam-modules, login and su will always reject the request.

    Best Regards,
    --
    Nekral


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

+ Reply to Thread