Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.devel > #108690
| From | Bastien Roucariès <rouca@debian.org> |
|---|---|
| Newsgroups | linux.debian.devel |
| Subject | Re: HFS/HFS+ are insecure |
| Date | 2023-07-21 12:00 +0200 |
| Message-ID | <GTV5w-1IgO-21@gated-at.bofh.it> (permalink) |
| References | <GTV5w-1IgO-23@gated-at.bofh.it> <GTG6t-1z5m-7@gated-at.bofh.it> <GTG6t-1z5m-31@gated-at.bofh.it> <GTTGp-1HxK-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
[Multipart message — attachments visible in raw view] - view raw
Le vendredi 21 juillet 2023, 08:20:12 UTC Matthew Garrett a écrit : Hi > On Thu, Jul 20, 2023 at 07:56:12PM +0200, Marco d'Itri wrote: > > Package: src:linux > > Severity: normal > > > > You are totally correct. > > Kernel team, please blacklist HFS/HFS+ for automounting. > > Isn't this a userland policy decision? udisks will happily trigger a > module load for hfsplus if udev has identified it, and I don't think > there's a trivial mechanism for the kernel to disable that. I believe > the only way for the kernel to disable automounting would be to disable > the drivers entirely (which we don't want to do), so this probably needs > to be assigned elsewhere rather than being a linux bug. > > (Or, alternatively, we could move hfs(+) support to FUSE and provide > extremely tight seccomp policies around them, and then drop kernel > support, but even though this has been talked about a bunch I haven't > seen anyone try to implement it) I vaguely remember that someone implement a fuse over uml (user space linux) I used it last time to read in user space some crappy filesystem I somebody has better memory than me, it could be an idea Bastien > >
Back to linux.debian.devel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Bug#1041552: HFS/HFS+ are insecure Marco d'Itri <md@Linux.IT> - 2023-07-20 20:10 +0200
Re: HFS/HFS+ are insecure Matthew Garrett <mjg59@srcf.ucam.org> - 2023-07-21 10:30 +0200
Re: HFS/HFS+ are insecure Marco d'Itri <md@Linux.IT> - 2023-07-21 11:00 +0200
Re: HFS/HFS+ are insecure Magissia <debianlist@magissia.com> - 2023-07-21 11:10 +0200
Re: HFS/HFS+ are insecure Martin Steigerwald <martin@lichtvoll.de> - 2023-07-21 12:10 +0200
Re: HFS/HFS+ are insecure Bastien Roucariès <rouca@debian.org> - 2023-07-21 13:00 +0200
Re: HFS/HFS+ are insecure Bastien Roucariès <rouca@debian.org> - 2023-07-21 13:10 +0200
Re: HFS/HFS+ are insecure Matthew Garrett <mjg59@srcf.ucam.org> - 2023-07-21 19:40 +0200
Re: HFS/HFS+ are insecure Ben Hutchings <ben@decadent.org.uk> - 2023-07-23 02:40 +0200
Re: HFS/HFS+ are insecure Magissia <debianlist@magissia.com> - 2023-07-21 11:20 +0200
Re: HFS/HFS+ are insecure Bastien Roucariès <rouca@debian.org> - 2023-07-21 12:00 +0200
Re: HFS/HFS+ are insecure Marco d'Itri <md@Linux.IT> - 2023-07-21 12:20 +0200
Re: HFS/HFS+ are insecure Bastien Roucariès <rouca@debian.org> - 2023-07-21 12:30 +0200
Re: HFS/HFS+ are insecure Bastien Roucariès <rouca@debian.org> - 2023-07-21 13:10 +0200
Re: HFS/HFS+ are insecure Paul Wise <pabs@debian.org> - 2023-07-22 09:50 +0200
Re: HFS/HFS+ are insecure Matthew Garrett <mjg59@srcf.ucam.org> - 2023-07-22 10:00 +0200
Re: HFS/HFS+ are insecure Jonas Smedegaard <jonas@jones.dk> - 2023-07-22 10:30 +0200
Re: HFS/HFS+ are insecure Matthew Garrett <mjg59@srcf.ucam.org> - 2023-07-22 10:40 +0200
Re: HFS/HFS+ are insecure Jeremy Stanley <fungi@yuggoth.org> - 2023-07-22 14:50 +0200
Re: HFS/HFS+ are insecure Paul Wise <pabs@debian.org> - 2023-07-25 06:40 +0200
Re: HFS/HFS+ are insecure Paul Wise <pabs@debian.org> - 2023-07-25 06:30 +0200
Re: HFS/HFS+ are insecure Bastien Roucariès <rouca@debian.org> - 2023-07-21 12:20 +0200
Re: HFS/HFS+ are insecure Bastien Roucariès <bastien.roucaries@cyu.fr> - 2023-07-21 12:30 +0200
Re: HFS/HFS+ are insecure Seth Arnold <seth.arnold@canonical.com> - 2023-07-21 23:20 +0200
csiph-web