On Wed, Mar 30, 2011 at 06:31:53PM +0300, Phil Carmody wrote:
> On 30/03/11 12:23 +0100, Colin Watson wrote:
> > On Wed, Mar 30, 2011 at 11:49:48AM +0300, Phil Carmody wrote:
> > > I performed the upgrade to 1:5.5p1-6 months ago, I don't know what
> > > version I was coming from. All I know is that my customised
> > > sshd_config was overwritten during the upgrade. As this 'upgrade'
> > > resulted in the opening of world-facing ports against my will, I
> > > consider it to not just be a grave error as it's not just a loss
> > > of data, but also a security issue.
> >
> > The previous comments from Matthew and myself in this bug still stand.
> > Please provide:
> >
> > * /var/log/dpkg.log* (which may show what version you were coming
> > from)
>
> -- 8< --
> # zgrep openssh /var/log/dpkg.log*
> /var/log/dpkg.log.1:2011-02-09 03:06:06 upgrade openssh-server 1:5.1p1-5
> 1:5.5p1-6
[...]
> > * /etc/ssh/sshd_config
>
> Well, right now it's the default from the package, that's the bug, see.
I'd really like an exact copy, just to make sure. The default text can
change from version to version, and it would be helpful to be able to
double-check it against my revision control repository.
> Subsystem sftp /usr/lib/openssh/sftp-server
>
> UsePAM yes
(For example, the lack of a comment here indicates that the creation of
the original version of this file predated 1:5.2p1-1.)
> > * any other /etc/ssh/sshd_config.* files, especially
> > /etc/ssh/sshd_config.dpkg-old
>
> No such files.
Thanks for the information.
> > > Chatting with a debian dev, the idea of this possibly being a
> > > dpkg bug was mentioned. Has that possibility been looked into at
> > > all?
> >
> > I don't know whom you were speaking to, but that seems highly unlikely
> > here; /etc/ssh/sshd_config is managed by the openssh-server maintainer
> > scripts, not by dpkg as some configuration files are. In any event,
> > this wouldn't be a productive first line of investigation - if it were
> > true, we'd arrive at it by other means.
>
> It's all very well taking a superior tone,
I didn't mean that to be a superior tone. Part of good debugging is
knowing where to start, and knowing which lines of enquiry aren't worth
pursuing to start with because they're unlikely and in any case don't
produce many leads. This isn't being superior - it's just trying to
save time.
I never start investigating package bugs by looking for dpkg bugs. I
certainly have run across dpkg bugs as a result of investigating bugs
reported against some other package, but it's not the place to start.
Obviously, if you want to put me in touch with the developer you were
talking to, I can ask them if they spotted something I haven't.
> but so far you appear to have made no progress in 7 years on this bug.
It's been stalled for practically all of that time waiting for
information; you're the first person who's replied with the information
we asked for seven years ago. I have plenty of bugs to work on that
*do* have enough information, without trying to tease things out of the
blocked ones as well (especially when they looked like isolated
occurrences, not systemic problems)!
> However, the information you provide does at least narrow down places
> where the issue could be. So let's crack open the postinst, which seems
> to be the only thing that really touches the ssh_config...
>
> Apart from function definitions, the first things it does are fix_doc_symlink
> which does nothing interesting, and create_sshdconfig, so let's look at that:
>
> create_sshdconfig() {
> if [ -e /etc/ssh/sshd_config ] ; then
>
> # lots of things that can modify /etc/ssh/sshd_config,
> # but which don't keep a backup anywhere.
>
> return 0
> fi
>
> #Preserve old sshd_config before generating a new one
> if [ -e /etc/ssh/sshd_config ] ; then
>
> # How can we get here? Who is racing with us to create it?
>
> mv /etc/ssh/sshd_config /etc/ssh/sshd_config.dpkg-old
> fi
>
> # stuff
> }
>
>
> That script seems to explicitly document the behaviour reported in the
> bug, doesn't it?
No, not as far as I can see.
The first if block does a sequence of targeted upgrade operations for
specific changes, none of which should require a backup (not that it
would necessarily be a bad idea I suppose, but none of those operations
should overwrite user configuration, and generally the required changes
are such that if you didn't make them then sshd would be broken in some
way).
If those upgrade operations took place, then we return and skip the rest
of this function. Otherwise (i.e. there was no configuration file in
place) then we write out a new configuration file.
You're correct to observe "How can we get here?", because the answer is
that we can't; that second if block is dead code, and I've removed it
from my tree.
> The move should be in the first [ -e ], right at the top, surely?
No, as I hope the above explains. I think the dead code is just being
misleading, but it doesn't explain the bug.
Now, your dpkg.log indicates that the previous version was 1:5.1p1-5.
Can you confirm that all was well when you had that version?
Working through the logic: your report (and the other similar reports in
this bug log) states that you previously had /etc/ssh/sshd_config, so
you must have entered the first if block in create_sshdconfig. You
don't have /etc/ssh/sshd_config.dpkg-old, which rules out the block that
upgrades from pre-3.7 versions. dpkg.log indicates that $oldversion
should have been 1:5.1p1-5, so the only other piece of code in
create_sshdconfig that you should have hit was the one to handle
LogLevel SILENT. That calls this function:
fix_loglevel_silent() {
if [ "$(get_config_option LogLevel)" = SILENT ]; then
set_config_option LogLevel QUIET
fi
}
(Do you remember having set LogLevel SILENT?)
get_config_option is read-only. set_config_option does:
set_config_option() {
option="$1"
value="$2"
perl -le '[... code to set $option to $value ...]' \
"$option" "$value" \
< /etc/ssh/sshd_config > /etc/ssh/sshd_config.dpkg-new
chown --reference /etc/ssh/sshd_config /etc/ssh/sshd_config.dpkg-new
chmod --reference /etc/ssh/sshd_config /etc/ssh/sshd_config.dpkg-new
mv /etc/ssh/sshd_config.dpkg-new /etc/ssh/sshd_config
}
This seems straightforward enough; it's running under 'set -e', so any
failure would cause the whole script to exit. Even if that protection
failed somehow, the worst case I can imagine would be ending up with no
sshd_config at all - certainly not good, but not the symptom you
reported.
So far, I haven't been able to think of any logical failure in any of
this that might cause local changes to be erased in such a way that the
default file would be put back in place. Can you confirm that the file
you ended up with is I'm happy to install
code to ensure that there's a backup kept before calling any of the
targeted-upgrade functions, but I don't think that will really fix the
problem here. That leaves me still rather stumped.
I don't suppose you have /var/log/apt/term.log*? The output from dpkg
when it performed this upgrade might still be in one of those files.
I wonder, also, if some other package that you have locally installed is
interfering with things: another package fiddling with
/etc/ssh/sshd_config could explain this bug when looking at
openssh-server alone doesn't, and perhaps explain why I've only had a
few reports of this when it seems as though it should happen to either
everybody or nobody. Could you run 'dpkg -S sshd_config' and 'grep -r
sshd_config /var/lib/dpkg/info' to look for this kind of thing?
Thanks,
--
Colin Watson [cjwat...@debian.org]
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
