Bug#1056279: Bug#1057220: Looks like the systemctl links are gone but not the pm-utils ones
On Mon, Dec 18, 2023 at 10:09:10AM +0100, Marc Haber wrote: > Thanks for the work, I was never able to fully grasp the issue and the > inner workings of the solution, and thank you for allowing me to remain > silent during the process of finding and implementing the solution. I'd like to report that it Works For Me. I downgraded molly-guard and systemd to trixie and then did an upgrade, which worked. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#1056279: Bug#1057220: Looks like the systemctl links are gone but not the pm-utils ones
On Sun, Dec 17, 2023 at 09:55:13PM -0800, Francois Marier wrote: > With respect to the presence of the real commands in the path, I'm not too > worried about it personally. Agreed. Molly-Guard is not a security tool, it provides basic safety against things like "typed shutdown -r now in the wrong window". Most people just give the same commands every time, for me it happens to be shutdown -r now, and if molly-guard reliably catches that then its job is done. It was never designed to prevent fully deliberate shots in one's foot by typing things like shutdown.someweirdsuffixthatnooneeverremembers -r now. Thanks for the work, I was never able to fully grasp the issue and the inner workings of the solution, and thank you for allowing me to remain silent during the process of finding and implementing the solution. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#1056279: Bug#1057220: Looks like the systemctl links are gone but not the pm-utils ones
Thank you Helmut and Chris for the helpful discussion. I have finally found some time to review your comments and the proposed molly-guard patches. While I'm still not 100% confident I understand the problem (and the fix), the solution you have settled on makes sense to me. With respect to the presence of the real commands in the path, I'm not too worried about it personally. I do agree it's unfortunate and it would be great if we could do this reliably without putting the diverted binary within easy reach, but at the end of the day, molly-guard will never catch all possible mistakes. As Helmut pointed out, it's already missing some cases (and it's always been possible to "init 6" as well), but I think it still provides a useful service if it catches the most common cases of accidental reboots. I had a similar dilemma for another package I maintain (safe-rm) and I've decided there to focus on the most common cases again to reduce complexity, and improve reliability. I will leave this for a few days in case others like Simó want to also chime in, but otherwise I am planning to upload to experimental this week and then unstable a few days later. Again many thanks for all of the work that has gone into solving this thorny problem. Francois
Bug#1057220: Looks like the systemctl links are gone but not the pm-utils ones
Hi everyone! On Tue, Dec 12, 2023 at 03:08:49PM +0100, Helmut Grohne wrote: [.. > Almost two weeks later, I'm back with what I hope is a solution. [..] > At the time of this writing, my preferred solution is restoring the lost > files in postinst. Fortunately, they are all symlinks in the case of > systemd-sysv, so restoring them is a rather simple matter. And this is > what the attached systemd patch does. [..] > This is not the option I'm going for now. Rather, given that systemd can > paper over the loss we can make the loss very unlikely by having > molly-guard not declare Breaks against systemd-sysv. As a result, apt no > longer sees a mutual conflict and no longer schedules temporary removal. > Thus, the loss scenario (usually) does not happen (though systemd-sysv > still mitigates it). I think this is a good plan, even though this means quite a few packages will have to do this in their maintainer scripts. I'll note that all affected packages will have to cooperate. [..] > /usr/sbin/halt -> /usr/sbin/halt.no-molly-guard I think this is a bit of a problem. My understanding of molly-guard's primary feature is to hide dangerous programs from $PATH, to avoid execution by overworked (or otherwise unattentive) operators. Keeping the dangerous programs in $PATH, under a similar-enough name that TAB-completion works, might be a serious downgrade in functionality to molly-guard's audience. I would suspect for other packages, like progress-linux-container, it might be worse, if they expect to completely disable these programs. As said above, this is all speculation, but I want to point this out, and maybe Francois can comment if this is acceptable for molly-guard? [..] > So now I am attaching the result of my work. I invite people to review > it (even though I understand that this is a complex matter). In > particular, I am also interested in what kind of tests I should be > performing in addition. I've asked you before on IRC about the test cases I thought to be the "interesting" ones and you pointed out they are already covered by the attached testcases and they have a success outcome. Chris
