sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] recon stops: "2015-02-11 07:09:48 Raising Sys.Break -- P


From: Daniel Kahn Gillmor
Subject: Re: [Sks-devel] recon stops: "2015-02-11 07:09:48 Raising Sys.Break -- PTree may be corrupted: Failure("remove_from_node: attempt to delete non-existant element from prefix tree")"
Date: Fri, 13 Feb 2015 13:47:33 -0500
User-agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu)

On Fri 2015-02-13 12:28:25 -0500, Kristian Fiskerstrand wrote:
> The startup-scripts provided by whichever sane distribution should fix
> this anyways to be a non-issue. From the Gentoo /etc/init.d/sks-db:
>
> start_pre()
> {
>     checkpath --owner sks:sks --directory \
>         ${SKS_DIR} ${SKS_DIR}/KDB ${SKS_DIR}/PTree
>     checkpath --owner sks:sks --file \
>         ${SKS_DIR}/*.log ${SKS_DIR}/KDB/* ${SKS_DIR}/PTree/*
> }

I don't know what checkpath is, but i assume it's intended to force the
ownership to a given user.

This suggests that (depending on the kernel version and configuration, i
guess) the sks process can actually take control over arbitrary files in
the same filesystem by hardlinking them into those locations.

For example, if someone uses the same filesystem for their entire
machine (a common configuration these days) then somoene who has taken
control of an sks instance can do:

 ln /etc/passwd ${SKS_DIR}/passwd.log

then at the next service start, /etc/passwd will be owned as sks:sks.

I don't think that's a great idea.

    --dkg



reply via email to

[Prev in Thread] Current Thread [Next in Thread]