FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 05-15-2011, 03:21 PM
Christoph Anton Mitterer
 
Default Bug#626641: cryptsetup: bug #587220 re-introduced

Hey...

I really don't wanna step on anyone's toes, especially not Jonas' (as
I'm in many cases quite satisfied and happy with his work for
cryptsetup), but sometimes I really wonder why this is packaged for
Debian at all, as it seems that it's merely intended to be a toy, and
not to be used for serious[0] cryptographic security.


Why do I say "toy",... well it seems as cryptsetup is handled like
just any normal program, or like lvm or mdadm.
Of course, from a technical point of view, this is true, it just sets
up some DM mappings, but the intention behind it (well at least if
used seriously) is strong security.


Of course we do not warn the user if he e.g. removes postgresql, that
he won't be able to use his DB any longer and we also don't warn him
that he'll get into troubles when removing lvm2.


But the difference is, that for those it would just cause breakage,
but not the (possible) complete destruction of a possibly long-term
and wide ranging security model.


Why?! Simply be cause one might be in desperate troubles, closing his
devices with sensitive data (consider the police already knock your
door).


Of course you can always argue "an expert user should know that", but
why - if absolutely unnecessary - should we let such things open, if
we can prevent the users from shooting in their foot.


You also wouldn't remove any secmem usage from gpg, just because an
expert user should know that he has to encrypt his swap partition.



And honestly, I don't see much of a difference with the warnings when
removing the running kernel.... or are there any bigger problems that
modules that should be newly loaded would not be found?!




Ideally, in a package like cryptsetup, operations should either fully
succeed or fully fail, so that a user at least knows that he's in
trouble.
For some of such bugs (e.g. exit code problems with
cryptdisks_start/stop) I was already able to convince Jonas after
sometimes long discussion to fix this, for others (init-scripts) he's
more or less bound by the policy which is IMO for historical reasons
wrong with respect to init-scripts (exit codes, and their handling as
config files[1]).


E.g. if I say /etc/init.d/cryptdisks stop, I expect that any
cryptdisks are stopped (well at least ne not "early" ones) and if this
didn't work for some _valid_[3] reason, a warning should be given and
in any circumstances exit code should be != 0.



What makes me really sad with respect to all this is, that Debian
obviously doesn't understand that things like cryptsetup must be
handled very sensitive and much more special than most other programs.
This is also, why I unfortunately must advise against using Debian's
cryptsetup in many cases on the dm-crypt mailinglist; at least if
"perfect"[0] security is desired.


And it's especially frustrating as for many things (some keyscripts,
etc.) alternatives or easy fixes would be available.


Words like "Messing with the running kernel, messing with 'essential'
packages..." (and I guess you mean implicitly that cryptsetup is not
essential) demonstrate quite well the wrong understanding of
cryptsetup... for someone who really wants to do serious security, the
functionality of most essential packages is completely uninteresting
(except as far as needed by cryptsetup)... because their failure would
just mean e.g. an unbootable (but still secure) system.



Apart from that,... I honestly don't think that it's necessary to
modify well written initscripts (and it shouldn't be) in 95% of all
cases.
Most configuration of the initscript itself or daemon parameters can
be don in /etc/defaults/<foo>...
And we already have lots of nicely written initscripts (e.g.
postgresql/zope) that show that it's even possible to run multiple
servers with one single init script.

If you need another good reason why something's wrong there, see [2].


Cheers,
Chris.


[0] Please don't use the argument that there's always a weaker element
in the chain, like torturing you to death.... if we argue like that we
could more or less completely drop many crypto/security packages.


[1] I mean the whole idea of configuring init-scripts via
/etc/defaults/<foo> already shows that something's going wrong there
... having a configuration file for a configuration file?!


[2] Which is not "the user broke the scripts".... but he did something
allowed like "remove but not purge".



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110515172155.14404atey8dobp1s@webmail.physik.uni-muenchen.de">http://lists.debian.org/20110515172155.14404atey8dobp1s@webmail.physik.uni-muenchen.de
 
Old 05-15-2011, 09:18 PM
Henrique de Moraes Holschuh
 
Default Bug#626641: cryptsetup: bug #587220 re-introduced

On Sun, 15 May 2011, Christoph Anton Mitterer wrote:
> And honestly, I don't see much of a difference with the warnings
> when removing the running kernel.... or are there any bigger
> problems that modules that should be newly loaded would not be
> found?!

An immediate panic makes it impossible for you to fix the system. Suble
differences in the kernel internal ABI can easily corrupt system state
and cause data loss or hard hangs. And you'll need to reboot using a
live-cd to repair in the first place if you removed the last kernel that
could run your box.

OTOH, all it takes to handle a dm-crypt device you forgot open is the
direct use of dmsetup, or simply reinstalling cryptsetup. Or a system
reboot/reset. Or a system power off.

> Ideally, in a package like cryptsetup, operations should either
> fully succeed or fully fail, so that a user at least knows that he's
> in trouble.

...

> E.g. if I say /etc/init.d/cryptdisks stop, I expect that any
> cryptdisks are stopped (well at least ne not "early" ones) and if
> this didn't work for some _valid_[3] reason, a warning should be
> given and in any circumstances exit code should be != 0.

Well, initscripts *are* mandated to FAIL if they cannot shutdown the
service. So yes, if there are cryptsetup disks open and you tell the
initscript to stop the service, and it cannot close the disks, it IS to
return failure.

OTOH, if there are *no* cryptsetup disks open to close in the first
place, it is to return success.

> 'essential' packages..." (and I guess you mean implicitly that
> cryptsetup is not essential) demonstrate quite well the wrong

It is not an 'essential package' by any means. However, we have a very
strict technical definition of what an 'essential package' is, and that
definition is directly related to the packaging system and a few other
system details.

So you likely misunderstood me there. It has nothing to do with how
essential cryptsetup is to your usage of a particular Debian system.

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110515211838.GA29544@khazad-dum.debian.net">http://lists.debian.org/20110515211838.GA29544@khazad-dum.debian.net
 
Old 05-16-2011, 01:51 AM
Christoph Anton Mitterer
 
Default Bug#626641: cryptsetup: bug #587220 re-introduced

On Sun, 15 May 2011 18:18:39 -0300, Henrique de Moraes Holschuh
<hmh@debian.org> wrote:
> OTOH, all it takes to handle a dm-crypt device you forgot open is the
> direct use of dmsetup, or simply reinstalling cryptsetup. Or a system
> reboot/reset. Or a system power off.
A system power off or dropping the mapping directly via dmsetup (which an
end-user does not necessarily know[0]) may not be enough:

I'm not sure whether milan has already implemented anything with respect
to this, but eventually the dm-crypt keys in memory (and perhaps the whole
memory itself) should be securely wiped.
Not sure whether he'll put that in the DM level, however, so you may be
right and dmsetup might be enough.

But than you depend on dmsetup and you just moved the problem.


>> Ideally, in a package like cryptsetup, operations should either
>> fully succeed or fully fail, so that a user at least knows that he's
>> in trouble.
> ...
Yes?
It's like gnupg, where you also want to have clear exit codes under any
circumstances, and not sometimes exit 0 though a signature verified wrong.
[2]

> Well, initscripts *are* mandated to FAIL if they cannot shutdown the
> service. So yes, if there are cryptsetup disks open and you tell the
> initscript to stop the service, and it cannot close the disks, it IS to
> return failure.
Have you actually had a look at the code? I doubt.
With the most recent upload (and this is the very reason why I've reopened
the bug), you can have the situation (package removed but not pruged) where
you say:
/etc/init.d/cryptdisks stop
and it gives you just $? = 0, as /lib/cryptsetup/cryptdisks.functions is
gone.


> OTOH, if there are *no* cryptsetup disks open to close in the first
> place, it is to return success.
THAT is fully ok of course,... and I've never said anything else...


> It is not an 'essential package' by any means. However, we have a very
> strict technical definition of what an 'essential package' is, and that
> definition is directly related to the packaging system and a few other
> system details.
>
> So you likely misunderstood me there. It has nothing to do with how
> essential cryptsetup is to your usage of a particular Debian system.
Yes I know that it's _not_ essential in the sense of the Debian Policy and
the "Essential: yes" control field, but, and this is what I'm trying to
explain the whole time, it is essential with respect to it's usage.
This means:

If you're someone who (seriously) wants to do disk encryption, than
cryptsetup (and that it perfectly works[2] in any circumstance is the most
essential thing on earth for you ;-)
And therefore I'd say, that there are some packages in debian (e.g.
cryptsetup, gnupg, openssl) which really need very special handling.

And this is also the reason why I've had quite some discussions with Jonas
before. While some of them were just rejected additions of features or
making the whole thing work in more setups (e.g. when /usr is network
mounted, etc. etc.) some were also about these small and inconsiderable
pieces, some may seem to be very nitpicking, but all of them are utterly
important when one wants real security.
This is not only "small things" like "secure" exit codes,.... but can be
things like securing the shell execution environment in all scripts (was
also reject, though it's a two liner), or adding documentation why
something is done, or (sometimes even more important) why something is
deliberately not done.

Again, I hope that Jonas doens't feel offended or so,... I just miss the
strong sense of care that is required for security in many places.


Cheers,
Chris.


[0] And we shouldn't exclude "end users" without deeper knowledge from
having a "secure as possible system" if they can get if "for free".


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: ebfc7fa78b646e772cb1b479fa574af0@imap.dd24.net">ht tp://lists.debian.org/ebfc7fa78b646e772cb1b479fa574af0@imap.dd24.net
 
Old 05-16-2011, 02:30 AM
Henrique de Moraes Holschuh
 
Default Bug#626641: cryptsetup: bug #587220 re-introduced

On Mon, 16 May 2011, Christoph Anton Mitterer wrote:
> With the most recent upload (and this is the very reason why I've reopened
> the bug), you can have the situation (package removed but not pruged) where
> you say:
> /etc/init.d/cryptdisks stop
> and it gives you just $? = 0, as /lib/cryptsetup/cryptdisks.functions is
> gone.

A package is, as a general rule, not supposed to allow itself to be removed
with the initscript indicating a failure state in the first place. There
are exceptions, but I cannot see why cryptsetup would be one.

> If you're someone who (seriously) wants to do disk encryption, than

Then you'd better know the real limits of the system you're using, and you'd
better know how to use it properly in the first place.

> Again, I hope that Jonas doens't feel offended or so,... I just miss the
> strong sense of care that is required for security in many places.

You must be entirely out of your mind if you even GET that feeling using
Debian, or any other normal Linux distro.

OTOH, I seriously doubt Jonas will be offended by any of this :-)

> [0] And we shouldn't exclude "end users" without deeper knowledge from
> having a "secure as possible system" if they can get if "for free".

End users without training will screw it up _every_ _time_. Or they will be
extremely easy prey to social engineering. It amounts to the same thing.

You have to actually design a system to be impossible to be used insecurely
in the first place for it to even last for a small while in the hands of
someone without a clue. Debian is not that system. Nor is your PeeCee
something that could be turned into such a system through the operating
system only.

I tire of this thread. There are apparently bugs in the initscripts, well,
if that's correct, just get them fixed. Then, the package will not allow
itself to be removed with crypt disks still active in the first place.

It'd have to switch to 'restart only _after_ upgrades, but stop on removal'
logic, though. And 'restart' will probably have to mean 'open any crypto
disks that are not currently open, close any that are not supposed to be
open anymore'. Or maybe 'do nothing'.

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110516023004.GA9453@khazad-dum.debian.net">http://lists.debian.org/20110516023004.GA9453@khazad-dum.debian.net
 
Old 05-16-2011, 10:24 PM
Jonas Meurer
 
Default Bug#626641: cryptsetup: bug #587220 re-introduced

Hey,

On 15/05/2011 Henrique de Moraes Holschuh wrote:
> On Mon, 16 May 2011, Christoph Anton Mitterer wrote:
> > With the most recent upload (and this is the very reason why I've reopened
> > the bug), you can have the situation (package removed but not pruged) where
> > you say:
> > /etc/init.d/cryptdisks stop
> > and it gives you just $? = 0, as /lib/cryptsetup/cryptdisks.functions is
> > gone.
>
> A package is, as a general rule, not supposed to allow itself to be removed
> with the initscript indicating a failure state in the first place. There
> are exceptions, but I cannot see why cryptsetup would be one.

I think that one is the trouble spot. Christoph doesn't agree with the
way, Debian manages initscripts. They're handled as conffiles by dpkg,
and for that reason aren't removed at 'apt-get remove', only if the
package is purged. For that reason, the situation that initscripts are
still around but the daemon/application they start/stop/whatever isn't,
is quite common. And it would be absurd if initscripts would exit wit $?
!= 0 in that case.

In case that this needs to be discussed, we should discuss the reasons
why initscripts are treated as conffiles in the first place, instead of
discussion symptoms of this decision.

> > If you're someone who (seriously) wants to do disk encryption, than
>
> Then you'd better know the real limits of the system you're using, and you'd
> better know how to use it properly in the first place.

I fully agree with Henrique here. My opinion is as simple as: If people
want do do something called serious, then they _really_ should know what
they're talking about. And if these people do remove a package from
their system, they should _not_ assume that it's functionality is still
provided.

> > [0] And we shouldn't exclude "end users" without deeper knowledge from
> > having a "secure as possible system" if they can get if "for free".
>
> End users without training will screw it up _every_ _time_. Or they will be
> extremely easy prey to social engineering. It amounts to the same thing.
>
> You have to actually design a system to be impossible to be used insecurely
> in the first place for it to even last for a small while in the hands of
> someone without a clue. Debian is not that system. Nor is your PeeCee
> something that could be turned into such a system through the operating
> system only.

Full ACK. Christoph, I guess that this is the argument I should have
used ealier.

> I tire of this thread. There are apparently bugs in the initscripts, well,
> if that's correct, just get them fixed. Then, the package will not allow
> itself to be removed with crypt disks still active in the first place.
>
> It'd have to switch to 'restart only _after_ upgrades, but stop on removal'
> logic, though. And 'restart' will probably have to mean 'open any crypto
> disks that are not currently open, close any that are not supposed to be
> open anymore'. Or maybe 'do nothing'.

Did I get you right that you suggest to start/stop/restart the
cryptdisks initscript in the debian maintainer scripts? Actually I don't
like that idea much. Most unlocked encrypted devices will be busy anyway
because being mounted while the system is running. And it's not the job
of debian maintainer scripts to unlock manually locked devices, or to
lock devices that are unlocked but not in use.

Appart from the general discussion about treatment of initscripts (see
above), I only see one point that's worth being discussed:

Is it appropriate to warn admins about unlocked devices when the
cryptsetup package is removed/purged? I still don't see the point, but
would be ok with adding a warning to prerm if people mind about it.

Greetings,
jonas
 
Old 05-16-2011, 10:57 PM
Christoph Anton Mitterer
 
Default Bug#626641: cryptsetup: bug #587220 re-introduced

On Tue, 2011-05-17 at 00:24 +0200, Jonas Meurer wrote:
> I think that one is the trouble spot. Christoph doesn't agree with the
> way, Debian manages initscripts. They're handled as conffiles by dpkg,
> and for that reason aren't removed at 'apt-get remove', only if the
> package is purged.
Yes I don't ;-) and also their exit codes in some cases.
But that's a different construction site ...

> For that reason, the situation that initscripts are
> still around but the daemon/application they start/stop/whatever isn't,
> is quite common. And it would be absurd if initscripts would exit wit $?
> != 0 in that case.
Here the problem is simply:
- dm-crypt devices might be open
- cryptsetup might be removed but not purged
- a user does /etc/init.d/cryptdisks stop (perhaps even from a script)
and believes in good faith that if $?=0 (and especially as even no
warnings appeared anyway) that his data is now secured
- but it is not.


> In case that this needs to be discussed, we should discuss the reasons
> why initscripts are treated as conffiles in the first place, instead of
> discussion symptoms of this decision.
Phew I guess there are already some requests against the policy open,..
both for this config-file-weirdness and for adhering to the (not so
unreasonable) LSB exit codes.

I've followed this some time and most arguments against these changes
seemed (at least to me) to be rooted in avoiding work (e.g. as it would
be then necessary to improve the init-scripts and make them "fully"
configurable via their respective /etc/default/foo).

Anyway,.. there probably won't be any progress soon.
So why not just fix this in cryptsetup now, as it's easily possible and
can avoid potential security breaches.

Again, cryptsetup is special here, not only because of its
security-nature, but also as it "leaves" behind running stuff after
removal (the dm-crypt devices).
"Normal" daemons like postgresql/apache/etc. don't have this problem, as
they're typically stopped on removal.


> I fully agree with Henrique here. My opinion is as simple as: If people
> want do do something called serious, then they _really_ should know what
> they're talking about. And if these people do remove a package from
> their system, they should _not_ assume that it's functionality is still
> provided.

Personally I don't share this view,... it should be possible for a end
user, if he already trusts Debian (which is obviously does), that he can
be given system as secure as possible, without knowing all the technical
details behind.

Because if this would be necessary, all users would have to read at
least the complete cryptsetup source-code, crypto kernel modules (and in
principle just everyting).


> Did I get you right that you suggest to start/stop/restart the
> cryptdisks initscript in the debian maintainer scripts?
That would be a bad idea,.. and it would most likely not even work, as
those devices are in use.


> Is it appropriate to warn admins about unlocked devices when the
> cryptsetup package is removed/purged? I still don't see the point, but
> would be ok with adding a warning to prerm if people mind about it.
While this is not a perfect solution,... it would allow us to conform to
Debian's strange handling of init-scripts while still doing everything
to at least inform the user about any possible security problems he may
encounter.
That's why I've suggested it before


Cheers,
Chris.
 
Old 05-16-2011, 11:17 PM
Russ Allbery
 
Default Bug#626641: cryptsetup: bug #587220 re-introduced

Christoph Anton Mitterer <christoph.anton.mitterer@physik.uni-muenchen.de>
writes:

> Phew I guess there are already some requests against the policy open,..
> both for this config-file-weirdness and for adhering to the (not so
> unreasonable) LSB exit codes.

> I've followed this some time and most arguments against these changes
> seemed (at least to me) to be rooted in avoiding work (e.g. as it would
> be then necessary to improve the init-scripts and make them "fully"
> configurable via their respective /etc/default/foo).

> Anyway,.. there probably won't be any progress soon.

Yes, I think it's very unlikely that any of this will change in Debian;
it's much more likely that Debian will migrate, at least partially, away
from SysV init scripts entirely towards something like upstart or systemd,
which make all of those proposals moot.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87d3jib5g9.fsf@windlord.stanford.edu">http://lists.debian.org/87d3jib5g9.fsf@windlord.stanford.edu
 
Old 05-17-2011, 01:25 AM
Henrique de Moraes Holschuh
 
Default Bug#626641: cryptsetup: bug #587220 re-introduced

On Tue, 17 May 2011, Christoph Anton Mitterer wrote:
> > For that reason, the situation that initscripts are
> > still around but the daemon/application they start/stop/whatever isn't,
> > is quite common. And it would be absurd if initscripts would exit wit $?
> > != 0 in that case.
> Here the problem is simply:
> - dm-crypt devices might be open
> - cryptsetup might be removed but not purged
> - a user does /etc/init.d/cryptdisks stop (perhaps even from a script)
> and believes in good faith that if $?=0 (and especially as even no
> warnings appeared anyway) that his data is now secured
> - but it is not.

Because the initscript returned status 0 when there were still
cryptsetup-managed dm-crypt devices active? If it does that, it is
broken.

Because the package allowed itself to be uninstalled while the initscript
was returning an error? If it does that, it is broken IMO.

Because the initscript returned status 0 when there were NO
cryptsetup-managed dm-crypt devices, but some other sort of dm-crypt
device? The user should have known better.

Yes, the package will be unremovable [unless you edit the initscript]
until all crypt devices are closed. That's how it is supposed to work in
the first place IMHO.

But I don't feel strongly about this.

> > In case that this needs to be discussed, we should discuss the reasons
> > why initscripts are treated as conffiles in the first place, instead of
> > discussion symptoms of this decision.
> Phew I guess there are already some requests against the policy open,..
> both for this config-file-weirdness and for adhering to the (not so
> unreasonable) LSB exit codes.

The conffile issue is not going to change, ever. Our respect for the
local administrator during package upgrades It is one of the major things
that sets Debian apart from the rest.

Initscript status codes could be changed, but that would require a very
very large amount of work. THAT is out-of-topic for this thread.

> > I fully agree with Henrique here. My opinion is as simple as: If people
> > want do do something called serious, then they _really_ should know what
> > they're talking about. And if these people do remove a package from
> > their system, they should _not_ assume that it's functionality is still
> > provided.

Note that I am against cryptsetup allowing itself to be removed while
devices *it manages* are still open in the first place.

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110517012545.GA680@khazad-dum.debian.net">http://lists.debian.org/20110517012545.GA680@khazad-dum.debian.net
 
Old 05-17-2011, 01:35 AM
Henrique de Moraes Holschuh
 
Default Bug#626641: cryptsetup: bug #587220 re-introduced

On Tue, 17 May 2011, Jonas Meurer wrote:
> > I tire of this thread. There are apparently bugs in the initscripts, well,
> > if that's correct, just get them fixed. Then, the package will not allow
> > itself to be removed with crypt disks still active in the first place.
> >
> > It'd have to switch to 'restart only _after_ upgrades, but stop on removal'
> > logic, though. And 'restart' will probably have to mean 'open any crypto
> > disks that are not currently open, close any that are not supposed to be
> > open anymore'. Or maybe 'do nothing'.
>
> Did I get you right that you suggest to start/stop/restart the
> cryptdisks initscript in the debian maintainer scripts? Actually I don't
> like that idea much. Most unlocked encrypted devices will be busy anyway
> because being mounted while the system is running. And it's not the job
> of debian maintainer scripts to unlock manually locked devices, or to
> lock devices that are unlocked but not in use.

Then, 'stop' tries to close all managed crypto devices and aborts *with
an error* if it cannot. 'Start' tries to open all managed crypto
devices, and aborts *with an error* if it cannot.

And 'restart' should not be supported, and return with the appropriate
error, or it could just be stop+start. You likely don't want to run
this on package upgrades.

You'd still have to call 'stop' and abort the package removal in prerm
[when removing the package. You will have to diferentiate the various
reasons for why prerm is called] if it cannot close all crypto devices
it manages. And 'start' on postinst, of course.

> Appart from the general discussion about treatment of initscripts (see
> above), I only see one point that's worth being discussed:
>
> Is it appropriate to warn admins about unlocked devices when the
> cryptsetup package is removed/purged? I still don't see the point, but
> would be ok with adding a warning to prerm if people mind about it.

Well, I think it is not appropriate to even let the package get removed
in the first place if there are devices still open.

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110517013512.GB680@khazad-dum.debian.net">http://lists.debian.org/20110517013512.GB680@khazad-dum.debian.net
 
Old 05-17-2011, 11:21 AM
Christoph Anton Mitterer
 
Default Bug#626641: cryptsetup: bug #587220 re-introduced

On Mon, 16 May 2011 22:35:12 -0300, Henrique de Moraes Holschuh
<hmh@debian.org> wrote:
> Then, 'stop' tries to close all managed crypto devices and aborts *with
> an error* if it cannot. 'Start' tries to open all managed crypto
> devices, and aborts *with an error* if it cannot.
>
> And 'restart' should not be supported, and return with the appropriate
> error, or it could just be stop+start. You likely don't want to run
> this on package upgrades.
>
> You'd still have to call 'stop' and abort the package removal in prerm
> [when removing the package. You will have to diferentiate the various
> reasons for why prerm is called] if it cannot close all crypto devices
> it manages. And 'start' on postinst, of course.

I'm not totally sure why, but also don't like the idea calling these from
the maintainer scripts.
Especially (but I'm not sure on this) as it might ignore any
non-crypttab-managed dm-crypt devices.


Still, the IMHO best solution would be:
- let any scripts fail with $? != 0 if the action they're expected to
perform failed
=> this however does not comply with the crude Debian init-scripts
policy
AND
- if cryptsetup is removed OR purged, give a big fat debconf-prio-low
warning that devices a b c are still open, and cannot be closed using
cryptsetup, if the user decides to continue.


Then we've warned/instructed the interactive user and we've also secured
any (clean[0]) script usage of the scripts within the cryptsetup package.


> Well, I think it is not appropriate to even let the package get removed
> in the first place if there are devices still open.
This would make removal of the package impossible, if you e.g. use
dm-crypt for the root-fs.


Happy hacking,
Chris.


[0] Of course we cannot force any users to check the exit codes,.. but
this is then really their fault.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: c980f1ea803695b21b3ed29ecc88ffd4@imap.dd24.net">ht tp://lists.debian.org/c980f1ea803695b21b3ed29ecc88ffd4@imap.dd24.net
 

Thread Tools




All times are GMT. The time now is 07:27 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org