On Fri, Sep 11, 2015 at 09:14:39AM -0400, Phil Susi wrote:
> On 9/11/2015 7:46 AM, Andreas Henriksson wrote:
> >That was my point, but unless you know the correct path to pass I'd
> >say not passing any PATH at all is better the passing an incorrect
> >one. If cryptmount sanitized the environment (
On 9/11/2015 7:46 AM, Andreas Henriksson wrote:
That was my point, but unless you know the correct path to pass I'd
say not passing any PATH at all is better the passing an incorrect
one. If cryptmount sanitized the environment (if it did not want
the user to be in control of the environment) it
Hello again.
On Fri, Sep 11, 2015 at 11:43:15AM +0100, Paul Martin wrote:
[...]
> Should the caller of /sbin/fsck need knowledge about the other paths
> where the various fsck.* programs might lurk? It knows where
> /sbin/fsck is, and that's all that should matter. It could even be
> argued that
On Fri, Sep 11, 2015 at 10:14:38AM +0200, Andreas Henriksson wrote:
> We can't have it both ways. Some people want PATH to be used instead
> of hard-coding paths to search for fsck.* helpers, now you report
> that passing an incorrect PATH will not work and you want it
> hard-coded I'm incline
Hello Paul Martin.
Thanks for your bug report.
On Fri, Sep 11, 2015 at 12:31:09AM +0100, Paul Martin wrote:
> Package: util-linux
> Version: 2.27-1
> Severity: important
> Control: affects -1 cryptmount
>
> This breaks cryptmount when run as a user.
[...]
> It is possible to work around this cha
Package: util-linux
Version: 2.27-1
Severity: important
Control: affects -1 cryptmount
This breaks cryptmount when run as a user. cryptmount tries to use
/sbin/fsck to check the filesystem, /sbin/fsck fails to be able to run
the correct filesystem check, returns an error and cryptmount refuses
6 matches
Mail list logo
