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, 10:52 AM
Jonas Meurer
 
Default Bug#626641: Bug#626641: cryptsetup: bug #587220 re-introduced

Hey,

@debian-devel: this is about a bugreport against cryptsetup. The
submitter suggests that cryptsetup should print a warning at package
removal, that locking dm-crypt devices is no longer possible.

I rather think that this is a obvious information, and making it
explicit is not required.

On 14/05/2011 Christoph Anton Mitterer wrote:
> On Sat, 14 May 2011 16:22:30 +0200, Jonas Meurer <jonas@freesources.org>
> wrote:
> > If people remove the package cryptsetup from their system, I hope they
> > know what they do. And I hope that they don't remove the package in case
> > that they still need it.
> >
> > Once the cryptsetup package is removed, they will not be able to setup
> > and/or unlock encrypted dm-crypt devices anyway.
> >
> > And if people really remove the cryptsetup package and still expect its
> > initscript to work afterwards, we really cannot help them.
>
> I don't think that's the appropriate way to solve this... so I'd suggest
> the following compromise:
>
> - We agree that it's fine to "break" if people are stupid and delete the
> cryptdisk.functions.

Ok, agreed on that.

> - But if the package is installed and removed (but not purged) some
> additional caution should be taken. I'd suggest using e.g. debconf (with a
> priority of "high", to warn that cryptdisks are still open (if any) any
> might not be closed anymore correctly afterwards.
> This does not only solve any meta-security issues (as people are now
> explicitly warned), but it also prevents any problems of dm-crypt-mappings
> that are still open any cannot be closed anymore (well at least not with
> cryptsetup itself).

While I do understand your motivation, I don't think that a warning as
removal time is appropriate. If people remove the cryptsetup package,
they should expect, that the functionality provided by the package goes
away with the package. After all they *remove* software.

I can imagine loads of software that whould have to warn the user while
being removed. This is valid for any kind of crypto applications at
least.

But let me think about it a bit. I'd love to hear a third opinion about
it. I've cc-ed debian-devel to see what others think.

Checking for unlocked dm-crypt devices at cryptsetup package removal,
and warn the user only in case s/he has open dm-crypt devices, might be
an option.

> Perhaps specifically adding a notice there, which tells that this could be
> security relevant, as the user cannot use cryptsetup to close the devices
> /dev/abc ... to /dev/efg anymore (as well as scripts depending on it)....
> and that he'll probably not even be noticed.



> The later is IMHO good and common practise, e.g. all linux-image-*
> packages warn you if you're about to remove the running kernel (and even
> give you the opportunity to abort).

This is a different case, as removing the running kernel and all related
kernel modules will most likely *break* your running system in a fashion
that you no longer can intervent. Thinks like a kernel panic are likely.

> I guess this is a good compromise in following the debian policy, having
> the best possible user experience (no situations in where he cannot close
> already open devices anymore) and also warning about the fact that he might
> not be able to reliably close his dm-crypt mappings.
>
>
> Still I think that an exit code != 0 is the better solution,... but that's
> a general problem of the way debian handles it's initscripts.

I see your point. And I don't know the reasons why initscripts are
treated as config files in the first place (beside them being in /etc).
But this bugreport is not the place to discuss things like that. Raise
them on debian-devel if you like to propose a better solution.

Greetings,
jonas
 
Old 05-15-2011, 12:03 PM
Henrique de Moraes Holschuh
 
Default Bug#626641: Bug#626641: cryptsetup: bug #587220 re-introduced

On Sun, 15 May 2011, Jonas Meurer wrote:
> > - But if the package is installed and removed (but not purged) some
> > additional caution should be taken. I'd suggest using e.g. debconf (with a

"should"? We hardly hand-hold our users that much. You have removed the
package, all functionality it provides is *GONE*. It *is* *that* *simple*,
and it is the truth for _ALL_ packages.

In fact, it is a serious bug for any package in the removed-but-not-purged
state to affect the running system in any way other than use up some storage
and dpkg database space.

> While I do understand your motivation, I don't think that a warning as
> removal time is appropriate. If people remove the cryptsetup package,
> they should expect, that the functionality provided by the package goes
> away with the package. After all they *remove* software.

Agreed. You *could* use postrm to output a single line, no-debconf, to the
terminal, that states "cryptsetup: package removed, all cryptdisk functions
are now unavailable". But this is _entirely_ unnecessary IMO.

> I can imagine loads of software that whould have to warn the user while
> being removed. This is valid for any kind of crypto applications at
> least.

And any critical services, etc. No, let's not go down that path. At most
we do it for bootloaders and the kernel, and AFAIK we're not doing much of
it even for those two very small classes of packages, even.

We usually warn only when it will break your system _right then_, and
probably make things very hard to fix. Messing with the running kernel,
messing with 'essential' packages...

> Checking for unlocked dm-crypt devices at cryptsetup package removal,
> and warn the user only in case s/he has open dm-crypt devices, might be
> an option.

That one would make sense, actually.

> I see your point. And I don't know the reasons why initscripts are
> treated as config files in the first place (beside them being in /etc).

Because we often have to modify them locally, and it is no rare thing
either.

--
"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: 20110515120316.GA32677@khazad-dum.debian.net">http://lists.debian.org/20110515120316.GA32677@khazad-dum.debian.net
 
Old 05-17-2011, 11:55 AM
Jonas Meurer
 
Default Bug#626641: Bug#626641: cryptsetup: bug #587220 re-introduced

Hey,

On 17/05/2011 Christoph Anton Mitterer wrote:
> On Mon, 16 May 2011 22:25:45 -0300, Henrique de Moraes Holschuh
> <hmh@debian.org> wrote:
> > Because the initscript returned status 0 when there were still
> > cryptsetup-managed dm-crypt devices active? If it does that, it is
> > broken.
> AFAIU just this happens right now.

yes, and this is the way it's supposed to be:

- if the cryptsetup package is installed, the action stop will exit with
$? != 0 in case any crypttab-listed dm-crypt device fails to stop
(only the case for cryptdisks-early)

- if the cryptsetup package is removed but not purged, the initscript
will exit with $? = 0 in any case, as neither the cryptsetup binary,
nor the functions file at /lib/cryptsetup/cryptdisks.functions is
available on the system.

> > 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.
> Actually I'm not sure on how /etc/init.d/cryptdisks and -early are
> intended with respect to this.
> Jonas, should they also handle (i.e. close) any unmanaged dm-crypt
> devices?
> Wouldn't be to bad, if stopping is just tried for any open device e.g. on
> shutdown, would it?

no, that's a very bad idea. actually, cryptsetup is *one* tool to manage
dm-crypt devices, it's not *the*only*one*. and it's a very very bad idea
to interfere in the dm-crypt management of other tools.

> > Note that I am against cryptsetup allowing itself to be removed while
> > devices *it manages* are still open in the first place.
> The more I think about it... the more I could like the idea,... but ONLY
> if it refuses to be removed if *any* dm-crypt device is still open.
> We really shouldn't make different grades of devices where one handled
> more important than the other.

cryptsetup is not like the kernel! several other tools (take a look at
cryptmount for example) might still be available, which allow the user
to manage unlocked (and locked) dm-crypt devices.

greetings,
jonas
 
Old 05-17-2011, 05:27 PM
Jonas Meurer
 
Default Bug#626641: Bug#626641: cryptsetup: bug #587220 re-introduced

Hey,

On 17/05/2011 Jonas wrote:
> On 17/05/2011 Christoph Anton Mitterer wrote:
> > - 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.
>
> At the moment I consider this as the best solution.

I just implemented that to the cryptsetup package in the svn repository.
Feel free to give it a try and see whether it works for you.

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

On Tue, 2011-05-17 at 13:48 +0200, Jonas Meurer wrote:
> - cryptsetup is not the only userspace tool which manages dm-crypt
> devices. Low-level tools like dmsetup, udev, hal; commandline tools
> like cryptmount and gui applications like gnome-mount etc. might
> unlock/lock encrypted devices as well.
That's a good point, I've completely forgot, when I've said in another
email, that I _could_ live with a cryptsetup package whose removal fails
if the are still open devices left.


> - the cryptdisks initscript only manages dm-crypt devices which are
> listed in the crypttab. Therefore otherwise unlocked devices are
> ignored.
Though this is another issue:
Wouldn't it make sense to try at the very end "just before
shutdown/reboot" to close any remaining _non managed_ dm-crypt devices?

Perhaps we should as Milan, if the same effect is automatically done by
the kernel itself.


> > 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
>
> Sorry Christoph, but this is simply not an option.
Out of curiosity: Did someone from the policy guys came and request this
from you? Cause we had it that way for some time now.


> > - 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.
>
> At the moment I consider this as the best solution.
Nice to hear :-)


Cheers,
Chris.
 
Old 05-21-2011, 12:13 PM
Jonas Meurer
 
Default Bug#626641: Bug#626641: cryptsetup: bug #587220 re-introduced

Hey,

On 20/05/2011 Christoph Anton Mitterer wrote:
> On Tue, 2011-05-17 at 13:48 +0200, Jonas Meurer wrote:
> > - cryptsetup is not the only userspace tool which manages dm-crypt
> > devices. Low-level tools like dmsetup, udev, hal; commandline tools
> > like cryptmount and gui applications like gnome-mount etc. might
> > unlock/lock encrypted devices as well.
> That's a good point, I've completely forgot, when I've said in another
> email, that I _could_ live with a cryptsetup package whose removal fails
> if the are still open devices left.
>
>
> > - the cryptdisks initscript only manages dm-crypt devices which are
> > listed in the crypttab. Therefore otherwise unlocked devices are
> > ignored.
> Though this is another issue:
> Wouldn't it make sense to try at the very end "just before
> shutdown/reboot" to close any remaining _non managed_ dm-crypt devices?

I much prefer the solution that the cryptdisks initscripts manage only
the devices they're taught to take care of. In other words only the
devices listed in crypttab.

I see the point that devices might be open that aren't closed properly
at shutdown, but first I assume that kernel closes them, and second I
don't want to start messing around with devices which are not properly
closed by other software for whatever reason.

> > Sorry Christoph, but this is simply not an option.
> Out of curiosity: Did someone from the policy guys came and request this
> from you? Cause we had it that way for some time now.

Not "policy guys" as these don't exist. every maintainer is responsible
for keeping her/his packages policy compliant. but yes, there was a
bugreport: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625468

Greetings,
jonas
 

Thread Tools




All times are GMT. The time now is 05:57 AM.

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