Hi Salvatore

> Hi David
> 
> On Thu, Jan 10, 2013 at 10:16:35AM +0000, David Weber wrote:
> > > Hi David
> > > 
> > > On Mon, Jan 07, 2013 at 09:06:53AM +0000, David Weber wrote:
> > > > > Attached is the debdiff contianing these three refreshed for the
> > > > > version in unstable and testing. But I'm not yet ready to propose a
> > > > > NMU. Testing of the resulting package is welcome!
> > > > 
> > > > Thanks for the debdiff!
> > > > 
> > > > It works as expected: It creates the files with the right 
> > > > permissions without breaking functionality.
> > > > 
> > > > A problem could be that the files aren't freshly created by a simple
> > > > restart of the daemon. Should something be done about that?
> > > > 
> > > > Some options could be:
> > > > - Notify the user to stop libvirtd and sanlock and run 
> > > > rm /var/run/sanlock/sanlock.sock; rm /var/log/sanlock.log
> > > > 
> > > > - Change the file permissions through the package update
> > > > 
> > > > - Do nothing because most likely nobody uses sanlock on Debain atm.
> > > 
> > > I have not a final answer here, but it might be easy to implement like
> > > libvirt-bin does in postint, mabye only conditionally checking (so
> > > doing it during package update from a 'broken' version):
> > > 
> > [...]
> > > > if ! dpkg-statoverride --list "/var/log/sanlock.log" >/dev/null 2>&1; 
> > > > then
> > > # fix permissions
> > > fi
> > > [...]
> > > 
> > > and the same for /var/run/sanlock/sanlock.sock.
> > 
> > Great hint. I modified the patch in that way and also added the 
> > fix for #689696
> 
> Btw, after thinking about further on it: As both /var/log/sanlock.log
> and /var/run/sanlock/sanlock.sock are not files installed by the
> package, I think the check with dpkg-statoverride is in this case
> wrong! Sorry about the wrong suggestion.
> 
> So I think it's best to remove this again.

Ops, thats right. I now check the permissions and change
them in case they are wrong


> 
> Regarding the second: I suggest to include in this upload only fixes
> compliant with the freeze policy: 
> 
> [1]: http://release.debian.org/wheezy/freeze_policy.html
> 
> (but I have not looked if #689696 can be considered RC).

Since it is a build fix, I guess it classifys

> 
> +sanlock (2.2-1.1) unstable; urgency=low
> +
> + * Fix CVE-2012-5638 sanlock world writable /var/log/sanlock.log. Thanks to 
> Salvatore Bonaccorso > (Closes: #696424)
> 
> ^^^^ would wrap this line
> 
> + Add patches cherry-picked from git repository:
> + - 0001-sanlock-remove-umask-0.patch
> + - 0001-sanlock-use-lockfile-mode-644.patch
> + - 0001-wdmd-use-lockfile-mode-644.patch
> + * Replace restrict field name (Closes: #689696)
> + Add patche cherry.picked from git repository:
> 
> ^^^^^ s{patche}{patch} and s{cherry.picked}{cherry picked}

Ops, fixed

> 
> Again thanks for your work!

Thank you too!

> 
> Regards,
> Salvatore
Cheers,
David

To: car...@debian.org
    696...@bugs.debian.org
Cc: martin.quin...@loria.fr
    j...@inutil.org
    a...@sigxcpu.org

Attachment: sanlock_cve2.debdiff
Description: Binary data

Reply via email to