Bug#765577: netboot install writes duplicates to 70-persistent-net.rules
Control: tags -1 confirmed Am 18.03.2015 um 19:50 schrieb Michael Biebl: Am 18.03.2015 um 18:52 schrieb Michael Biebl: Am 18.03.2015 um 18:15 schrieb Faidon Liambotis: Another less arbitrary/racy workaround I suggesed was a grep near the top of write_net_rules' write_rule() function. Since write_rule() operates under a lock, this would completely eliminate any kind of race here. I pitched this to Marco but he wasn't thrilled with the idea -- he said he'd prefer finding the root cause. I've done the change and tested it anyway, though, and it successfully aleviates this issue: I'm with Marco here. Before adding any workarounds, we need to understand what the underlying problem is. Otherwise we are adding cruft which nobody understands anymore a few years from now. Since I can't reproduce the issue and already have trouble keeping up with other bug reports, further investigation needs to be done by someone else. Btw, thanks for looking into this. Would be awesome if you can dig further and get to the bottom of this. Looks like a found a simple reproducer (this is on my work laptop) done during normal runtime of the system: $ rm /etc/udev/rules.d/70-persistent-net.rules $ while true ; do echo add /sys/class/net/eth0/uevent ; done I let this run for one or two seconds and had over 100 entries in 70-persistent-net.rules. udevd went totally nuts and consumed almost 100% CPU, but a simple systemctl restart systemd-udevd.service fixed that. So, while I don't have a solution yet, at least I have now a simple way to reproduce it reliably. Therefor marking the bug accordingly. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#761658: Please reopen this bug report
Hi, I agree: no nameserver → no resolution. Please reopen this bug report. Thank you! Carlo ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#765577: netboot install writes duplicates to 70-persistent-net.rules
Am 30.03.2015 um 04:56 schrieb Michael Biebl: Looks like a found a simple reproducer (this is on my work laptop) done during normal runtime of the system: $ rm /etc/udev/rules.d/70-persistent-net.rules $ while true ; do echo add /sys/class/net/eth0/uevent ; done I let this run for one or two seconds and had over 100 entries in 70-persistent-net.rules. udevd went totally nuts and consumed almost 100% CPU, but a simple systemctl restart systemd-udevd.service fixed that. So, while I don't have a solution yet, at least I have now a simple way to reproduce it reliably. Therefor marking the bug accordingly. I think I have a pretty good explanation now, why this happens and why the lock_rules_file() function does not really prevent this: Say we have multiple add events. NAME is not yet set for the interface. So we we call write_net_rules for all of them and they spin in lock_rules_file() and when they get their turn, they pick the next free name i.e. increase the counter. The problem happens if you have multiple add events *before* the rules file is written and NAME is not yet set. Those multiple add events could be the result of something calling udevadm trigger multiple times for example, as you rightfully pointed out Faidon. Talked to Marco via IRC and this seemed plausible to him. He also mentioned, that he might have a simple fix for it. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#765577: (no subject)
On Mar 18, Faidon Liambotis parav...@debian.org wrote:
Well, the root cause IMO is that 75-persistent-net-generator.rules is
inherently susceptible to races. It's my understanding that it's valid
for events to be triggered multiple times -- there are multiple places
in d-i that udevadm trigger is called, including start-udev (as
shipped by udev-udeb) which would trigger another set of add events
beyond the original hotplug one.
I do not think that this is valid in the sense that the kernel could
generate multiple add events, but removing all misuses of udevadm
trigger requires some work and may not even be possible at this time.
I see that we have independently devised the same fix, I am attaching
a test case and a more refined version of your patch.
--
ciao,
Marco
#!/bin/sh -e
rm -f /etc/udev/rules.d/70-persistent-net.rules
rmmod e1000e || true
modprobe e1000e
sleep 1
rm -f /etc/udev/rules.d/70-persistent-net.rules
iteration=0
while : ; do
iteration=$((iteration + 1))
if ! echo add /sys/class/net/eth0/uevent; then
echo Failed at iteration $iteration!
exit
fi
# do not send too many events to udev because they will all be queued
# and eventually processed
if [ $iteration -eq 2500 ]; then
echo Aborting at iteration $iteration!
exit
fi
done
--- /lib/udev/write_net_rules.orig 2015-03-30 05:18:43.228147201 +0200
+++ /lib/udev/write_net_rules 2015-03-30 06:00:39.181085432 +0200
@@ -117,6 +117,18 @@
basename=${INTERFACE%%[0-9]*}
match=$match, KERNEL==\$basename*\
+# build a regular expression that matches the new rule that we want to write
+new_rule_pattern=$(echo ^SUBSYSTEM==\net\, ACTION==\add\$match | sed -re 's/([\?\*])/\\\1/g')
+
+# Double check if the new rule has already been written. This happens if
+# multiple add events are generated before the script returns and udevd
+# renames the interfaces. See #765577 for details.
+if egrep -q $new_rule_pattern \
+$RO_RULES_FILE $([ -e $RULES_FILE ] echo $RULES_FILE); then
+ unlock_rules_file
+ exit 0
+fi
+
if [ $INTERFACE_NAME ]; then
# external tools may request a custom name
COMMENT=$COMMENT (custom name provided by external tool)
pgp0CXb73md6m.pgp
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#761658: Please do not default to using Google nameservers
also sprach Christoph Anton Mitterer cales...@scientia.net [2015-03-29 07:18 +0200]: So if resolved is used - and I'd guess that's the long term goal - then people would automatically get resolving - always. Even when they have /etc/resolv.conf (possibly intentionally) left empty and AFAIU the manpage, one cannot unset it. I imagine that in a few years, /etc/resolv.conf will be obsolete and no longer used in most cases (cf. xorg.conf, and others). While this is a good development in terms of ease of use, it does put a whole lot more weight on default choices made by upstream and Debian. At the moment, systemd upstream and Debian basically embrace Google and require people who don't want that to do extra work. If that's a direction to go, then shouldn't postfix also be configured by default to relay mail via GMail? -- .''`. martin f. krafft madduck@d.o @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#761658: Please do not default to using Google nameservers
Am Sonntag, 29. März 2015, 07:18:43 schrieb Christoph Anton Mitterer: On Sun, 2015-03-29 at 06:55 +0200, Michael Biebl wrote: Am 29.03.2015 um 06:35 schrieb Christoph Anton Mitterer: I'm really not inclined to start another security discussion, since that's already lost cause in Debian... but the appropriate way would be to reopen this bug, solve it so that no data/privacy leakage happen... or perhaps to retitle Debian Windows, I don't really appreciate this tone. You're not really convincing anyone this way only putting people off. The tone wasn't impolite or offensive to anyone,... and that security is just amongst further goals in Debian is simply a matter of fact. And AFAIU the problem of data/privacy leakage isn't just made up, is it? If the system falls back to google nameservers they will now anything one tries to resolve. And $ geoiplookup 8.8.8.8 GeoIP Country Edition: US, United States shows that it won't be only Google who knows ;-) So what exactly is it that you don't like, cause I don't understand it. Seriously, Michael, just because someone didn't start a message with hugs and cookies doesn't mean he meant anything offensive or unfriendly. Or are there already Code of Conflict cases running against me now or Marco because he used the word lunacy on someone else's work o.O I highly appreciate if the default of using google name server if nothing else is configured is removed from Debian´s systemd. I had a similar issue with Debian packaged Wordpress which appears to try to download fonts from Google unless I install a plugin to disable this, which I didn´t yet report. But really, if there is no DNS server configured I expect name resolution to *fail*, instead of the system asking any DNS server of choice by some who was not me. At least unless there is a DNS service that provably doesn´t track and save queries of users of it. As thats near to impossible to prove. And no, I do not want to have to configure the system for basic privacy. I do want this to be the default. This is Debian, no Google Play enabled Android device. So I kindly ask you to remove configuring some DNS server in systemd if the unlikely case none is configured elsewise. User desktops often use DHCP. Then they usually have DNS. And if someone configured network manually, for example for a server VM, please pretty please require that he gives a DNS server by itself. There are even cases where one may not want to have DNS resolution at all. If you want, add a dialog on desktop enviroment no dns server configured with choices like choose one from a list and enter one manually, but don´t do it implicetely. Users are not in control otherwise cause frankly, who would notice that the system would use Google name servers if none a configured? I bet most won´t even notice it. So they are *not* in control. Cause you can only be in control of what you *know*. I didn´t notice Wordpress accessing Google servers unless I installed Iceweasel request policy plugin. Thus I didn´t just sacrifice the privacy of myself, but also of my users *without* knowing so. I was very angry as I found out which remembers me to report a bug. I didn´t at that time as I even feared a harsh respone. If a systemd based system is used on a misconfigured router it may leak the privacy of any users behind it. I hope this gives a clear reasoning. Frankly I do not understand why this default has not already been removed long ago. Whats the case for *having* this as a default? Some minor convenience in the case someone messes up network configuration by not providing a DNS server? Just that it is in systemd upstream does not mean that it is good to have. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part. ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#761658: Please do not default to using Google nameservers
Am Sonntag, 29. März 2015, 08:28:20 schrieb martin f krafft: also sprach Christoph Anton Mitterer cales...@scientia.net [2015-03-29 07:18 +0200]: So if resolved is used - and I'd guess that's the long term goal - then people would automatically get resolving - always. Even when they have /etc/resolv.conf (possibly intentionally) left empty and AFAIU the manpage, one cannot unset it. I imagine that in a few years, /etc/resolv.conf will be obsolete and no longer used in most cases (cf. xorg.conf, and others). While this is a good development in terms of ease of use, it does put a whole lot more weight on default choices made by upstream and Debian. At the moment, systemd upstream and Debian basically embrace Google and require people who don't want that to do extra work. If that's a direction to go, then shouldn't postfix also be configured by default to relay mail via GMail? Frankly, nope. For the reasons I explained in my other post to this bug report. I understand better and better why I deleted my Google account some time ago. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part. ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Processed: Re: Bug#765577: netboot install writes duplicates to 70-persistent-net.rules
Processing control commands: tags -1 confirmed Bug #765577 [udev-udeb] netboot install writes duplicates to 70-persistent-net.rules Bug #777126 [udev-udeb] udev: duplicate eth? entries Added tag(s) confirmed. Added tag(s) confirmed. -- 765577: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765577 777126: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777126 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#761658: Please do not default to using Google nameservers
On Sun, 29 Mar 2015 05:57:22 +0200 m...@linux.it (Marco d'Itri) wrote: This default is not used as long as a resolver has been configured by the system administrator or provided by DHCP, and I see no value in allocating development time to break cases which currently work by removing support for a default. People do not need one if they do not want to configure one. Since the Google resolvers are a very reliable widely anycasted service which third parties are encouraged to use they actually look like a sane fail-safe default, hence I am closing this bug. The DNS query traffic to Google resolvers may be hijacked in some contries, or just blocked. For people who really need a default one, it's may be a better choice to use the default gateway as the default DNS resolver. Or we may patch systemd- resolved to scan the local network to find a usable DNS server. It's funny to see systemd-resolved. ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#761658: Please do not default to using Google nameservers
On Sun, 2015-03-29 at 12:47 +0200, Marco d'Itri wrote: So far, it is. If you still want to argue about this (which I something that I strongly recommend against!), then you should explain in detail the threat model that you are trying to address and how the current configuration would be worse than other configurations. The original reporter, I and some others did so before. I don't see a point in repeating an explanation of the same thread model over and over again. Either it's as it is, or the documentation is at least misleading. $ geoiplookup 8.8.8.8 GeoIP Country Edition: US, United States traceroutes from multiple non-US locations may surprise you. $ traceroute 8.8.8.8 traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets 1 [snip snap] 2 [snip snap] 3 [snip snap] 4 93.104.240.55 (93.104.240.55) 24.388 ms 24.773 ms 25.538 ms 5 209.85.253.113 (209.85.253.113) 25.002 ms 64.233.175.121 (64.233.175.121) 25.131 ms 209.85.252.215 (209.85.252.215) 25.808 ms 6 google-public-dns-a.google.com (8.8.8.8) 25.623 ms 15.634 ms 15.724 ms calestyo@heisenberg:~$ geoiplookup 209.85.253.113 GeoIP Country Edition: US, United States calestyo@heisenberg:~$ geoiplookup 64.233.175.121 GeoIP Country Edition: US, United States calestyo@heisenberg:~$ geoiplookup 209.85.252.215 GeoIP Country Edition: US, United States Nope, not really a surprise. And I'm Germany based. Unless all these hops would be anycasted, traffic goes into the US. And even if not, there is nothing that guarantees that this would never change, and even if, it's well known that subsidiaries of US companies are forced by US law to obey to US governmental agencies. I argue that alternative DNS roots are firmly in the camp of net.kooks, and there is more than enough history to support this. Were you around at the time of the newdom mailing list? Fun times... Be careful of who you choose to associate with, because you will be judged by your peers for it. I haven't said that *I* would endorse the switch to OpenNIC, have I? Quite the contrary actually. This was just an example that Michael should try to stay calm an not open a CoC case just because someone doesn't share his views. I did, in my reply. Short summary: have a resolv.conf file or use DHCP. As stated by the others, this is both non-obvious and non-standards behaviour, i.e. explicitly having to opt-out of default-Google-name-resolution (and potentially/likely surveillance/tracking). Now I'm for sure not a traditionalist who wants to keep things as they are just per se, but here I see only disadvantages in changing the way it used to be. No nameservers configured - no resolution. Done. What comes next? A google or aol account that's automatically set up with Debian installation? Which of course has no direct disadvantage to the user. Still it would be wrong. Then maybe you should work in the IETF to establish either: - well know IP addresses which will provide recursive DNS service (this may even work now that we have DNSSEC) Such a thing doesn't exist, because it's not necessary + would be bad design. For autoconfiguration of systems (including the resolvers) we already have plenty of mechanisms. - a best practice of running a caching resolver on every end user system (I highly doubt that this would be considered a good idea) I don't see how this affects this topic? But apart from that, it will probably be the future, at least when people want locally verified DNSSEC resolution. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#761658: Please do not default to using Google nameservers
On Mar 29, Christoph Anton Mitterer cales...@scientia.net wrote: And AFAIU the problem of data/privacy leakage isn't just made up, is it? So far, it is. If you still want to argue about this (which I something that I strongly recommend against!), then you should explain in detail the threat model that you are trying to address and how the current configuration would be worse than other configurations. $ geoiplookup 8.8.8.8 GeoIP Country Edition: US, United States traceroutes from multiple non-US locations may surprise you. Or are there already Code of Conflict cases running against me now or Marco because he used the word lunacy on someone else's work o.O I argue that alternative DNS roots are firmly in the camp of net.kooks, and there is more than enough history to support this. Were you around at the time of the newdom mailing list? Fun times... Be careful of who you choose to associate with, because you will be judged by your peers for it. Marco told you specifically, how you can configure this explicitly. Uhm? I just accidentally stumbled over this bug and I don't think he has told me anything in specific. I did, in my reply. Short summary: have a resolv.conf file or use DHCP. IMO, OpenNIC or anything else would have the same issues than Google: Then maybe you should work in the IETF to establish either: - well know IP addresses which will provide recursive DNS service (this may even work now that we have DNSSEC) - a best practice of running a caching resolver on every end user system (I highly doubt that this would be considered a good idea) -- ciao, Marco pgptDtQdpMvym.pgp Description: PGP signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#761658: Please do not default to using Google nameservers
btw: Letting people use unknowingly a specific nameserver may have also further consequences than just privacy leakage. Since e.g. the Google nameservers are well known to allow people to circumvent DNS blocks, they're quite likely under special observation by governmental agencies in autocratic countries like China, Turkey, etc. where internet censorship is daily practise. So if you use these services you may actually get into troubles... and I guess we don't make Debian just for people in safe countries. If you don't see the thread in the above schema, take the following comparable example: According to the US secretary of justice (IIRC), Tor is just used by criminals and paedophiles (o.O), and we all know since Snowden that people using Tor are specially flaged and that it has already happened that such people were taken into custody when crossing the US border. So we should perhaps not make Tor the default and maybe wikileaks.org the default homepage in browsers. Neither should we give people a Tor config that relays per default, cause it may get them really into troubles even in Europe. And it's not that I wouldn't support the goals of things like Tor - but the decision what to use and what not should be left at the user/admin in the form of a deliberate decision, and not an opt-out decsision. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Processed: tagging 762700
Processing commands for cont...@bugs.debian.org: tags 762700 + pending Bug #762700 [systemd] systemd: journald fails to forward some messages to syslog Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. -- 762700: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762700 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#761658: it's a security hole
How come this issue isn't RC? You're sending every DNS resolution attempt, and thus effectively the metadata on almost any TCP/IP connection, to a company well-known to collect and use this kind of data. This is worse than, say, Ubuntu's Unity Lens spyware. ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
