[buildd-tools-devel] Bug#597778: Bug#597778: Bug#597778: schroot: Stupid name restrictions is breaking existing setups for no good reason.

[Roger Leigh]

On Mon, Oct 18, 2010 at 01:26:05PM -0400, Len Sorensen wrote:
> On Fri, Sep 24, 2010 at 06:52:32PM -0400, Roger Leigh wrote:
> > While this change is clearly an annoyance to yourself, the severity
> > is certainly not grave, so I am changing it accordingly.  If the
> > change was causing irretrievable data loss, then the grave severity
> > would have been appropriate.
> > 
> > Your comments are also rather aggressive.  Please keep to the facts,
> > rather than using unnecessarily inflammatory language.  It's not
> > helpful, and is most certainly *not* appreciated.  Bug reports should
> > have the goal of improving the software, not abusing its developers.
> > Please bear that in mind, both in any replies to this email, and in
> > any future bug reports.
> 
> Perhaps I was a bit too aggresive.  I had a cold, it wasn't the first time
> this year schroot had broken things that previously worked without even
> a hint in the changelog that such breakage was being introduced.  In noen
> of the cases does there seem to be any good reason for breaking things.
> To me these breakages are so severe that a NEWS entry should have popped
> up warning the user that this was happening.

This is now documented in schroot's README.Debian file.  It could also
be put into NEWS.Debian.

> I don't think breaking things this close to a release with the intent
> of fixing it someday later is acceptable.  Why should configs from Lenny
> stop working when people move to Squeeze?  Are you going to put that in
> the release notes?  Are you going to have debconf pop up a warning to
> users that their configs are now potentially broken?

We can put it into NEWS.Debian to have this in a more prominent
place.

> > • we will allow more permissive chroot naming once the security
> >   implications have been throughly evaluated, and the code
> >   audited
> 
> So when is that going to happen?  If it isn't before squeeze is finallized
> then I think this change has to be reverted or at least vastly relaxed.
> It breaks too much as it is.

I'm currently writing my PhD thesis, and haven't got the time to
commit to it to get this completed before squeeze.  Squeeze is also
frozen, though it might be possible to get this in given it's fixing
a regression.

It won't be reverted in the short term.  As I said, it needs careful
review before that will happen, and I can't commit to that for the
next few months.  I think the best approach at this point is to
simply document the change more prominently in NEWS.Debian.

> > • you are free to modify the source to make this change yourself,
> >   at entirely your own risk
> 
> Well I had too, given I can't use it anymore without changing it.
> It has become useless to me as shipped upstream.
> 
> Certainly the filenames permitted by run-parts is way too restrictive
> and not a good source of a regex to use.

As I said, I'm in complete agreement.  It's not ideal and it does need
fixing.  But safety and security are the main concern, and I'll fix it
once they are addressed.

> I will happily write up a regex if I knew everything it needs to consider.

The particular regex isn't the issue.  It's the matter of auditing
all the code that uses filenames and chroot names to make sure it's
secure.  The regex is just enforcing the rules; we need to be sure
the rest of the code is safe in addition so that we can guarantee
it's secure when we do relax the regex.

> Also, it seems wrong for schroot to refuse to use ANY chroot if there
> is any chroot in any config with an "illegal" name.  So you can't even
> use the valid ones when any invalid ones are defined.

That's also by design.  If the configuration is broken, it needs fixing
before we can be sure it's safe.  We're merely erring on the side of
caution so the user can't inadvertently do something with unintended
catastrophic effects because the configuration was incorrect.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20101019/1698edea/attachment.pgp>