Your message dated Sun, 01 Jul 2018 01:42:58 +0100
with message-id <cc9bc58a4f419e5340929c590d3563fa85454a59.ca...@decadent.org.uk>
and subject line Re: protected_hardlinks is too broad - make it per-filesystem
instead?
has caused the Debian Bug report #709625,
regarding protected_hardlinks is too broad - make it per-filesystem instead?
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
709625: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709625
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: src:linux
Version: 3.2.41-2
Severity: normal
Hi,
I think that the new security feature to restrict hardlinks is a great
idea, but it is also causing me problems. In debian-cd, we rely on the
ability to make hardlinked copies of files from a debian mirror into
temporary disk trees. Since upgrading pettersson (the CD build box),
this broke due to the default protected_hardlinks setting. On that
system:
* we have a push mirror setup using the "archvsync" user;
* we build CDs using as the "debian-cd" user
These two user accounts explicitly don't share credentials: archvsync
can be triggered remotely so we don't trust it to be directly involved
in the CD build process. The debian-cd user explicitly does not have
write access to the mirror area on the machine, so as to ensure we
can't/don't make any changes to the mirror when building CDs.
For now, on that system we have changed the default settings via /proc
but it's not a real solution for us and DSA don't want to do it
permanently. I can see a few ways that we could change things:
* run things using the same account (not wanted, as described above)
* share a group between the users and make everything group-writable
(ditto)
* come up with a fakelink ld_preload lib like we have fakeroot (eww)
Alternatively, I'm pondering: if the main thrust of the hardlink
protection is to prevent attacks against system files, then it might
make more sense to change protected_hardlinks to be a per-filesystem
mount option. By all means protect the root filesystem etc., but for a
purely data-carrying filesystem it's a bit obstructive.
What do you think?
--
Steve McIntyre, Cambridge, UK. st...@einval.com
Google-bait: http://www.debian.org/CD/free-linux-cd
Debian does NOT ship free CDs. Please do NOT contact the mailing
lists asking us to send them to you.
--- End Message ---
--- Begin Message ---
Closing this since it's an upstream feature request and apparently
hasn't been pursused upstream.
Ben.
--
Ben Hutchings
Q. Which is the greater problem in the world today,
ignorance or apathy?
A. I don't know and I couldn't care less.
signature.asc
Description: This is a digitally signed message part
--- End Message ---
