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

Bug#581919: openssh-server: "bad ownership or modes for file $HOME/.ssh/authorized_keys" check too aggressive



On Sun, May 23, 2010 at 07:10:26AM +0100, Colin Watson wrote:
> On Sun, May 23, 2010 at 03:16:56AM +0200, Christoph Anton Mitterer wrote:
> > On Sat, 2010-05-22 at 19:55 +0100, Colin Watson wrote:
> > > It's not completely dropping security.  If the user is the only member
> > > of a group, then the group-writability confers no additional permissions
> > > and it's OK to allow it.
> > 
> > Well I've read the code for the ~/.ssh/config changes,... I mean it
> > seems ok at least at a first glance,... but I think it's more or less
> > only a heuristic and I guess upstream has it's reasons to not merge
> > it...
> 
> Wrong reasons, yes.  I corrected a significant mistake in their
> objection on the upstream bug and they never responded to that; and they
> also don't think that it's important for this part of the system to work
> by default (I assume that they don't use systems with user-private
> groups).  I expect to continue carrying the patch since I am not
> persuaded by their arguments.

Incidentally, don't take that the wrong way.  I respect upstream and for
the most part try to stay as close to them as I can (though the need to
carry the GSSAPI patch means there's something of a lower bound here).
But I also reserve my own judgement, particularly when problems
disproportionately affect Debian.

> > And what happens if group memberships changes just during that code
> > part?
> 
> I don't see a reason to care.  Let's say that all but one user is being
> removed from the group: now either the test fails, as it would have done
> beforehand, or it passes, as it would do afterwards.  Since the test is
> essentially just to protect the user from themselves, it doesn't matter
> that it races against passwd/group file changes.

A further and better reason is that only root can change group
memberships.  OpenSSH doesn't need to defend against attempts by root to
compromise their own system.

-- 
Colin Watson                                       [cjwatson@debian.org]



Reply to: