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
Attachment:
signature.asc
Description: Digital signature