Bug#336495: netatalk: spool directory not created during installation
Package: netatalk Version: 2.0.2-3 Severity: important The default installation of netatalk will not create /var/spool/netatalk/. This causes the papd childs to fail while trying to access the printer. As a result, the macintosh clients will be blocked untill the timeout occures. TODO: 1) Create the spool directory. 2) Make papd check for the spool directory on startup? 3) Make papd report errors to the client. (Verbose message possible?) -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.4.27-2-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages netatalk depends on: ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libcupsys2-gnutls10 1.1.23-10Common UNIX Printing System(tm) - ii libdb4.24.2.52-18Berkeley v4.2 Database Libraries [ ii libgssapi1-heimdal 0.6.3-10 Libraries for Heimdal Kerberos ii libpam-modules 0.76-22 Pluggable Authentication Modules f ii libpam-runtime 0.76-22 Runtime support for the PAM librar ii libpam0g0.76-22 Pluggable Authentication Modules l ii libslp1 1.0.11a-2OpenSLP libraries ii libwrap07.6.dbs-8Wietse Venema's TCP wrappers libra ii netbase 4.21 Basic TCP/IP networking system ii perl5.8.4-8 Larry Wall's Practical Extraction -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#631504: (no subject)
I have to agree with Klaus Knopper. This is ridiculous. Just because you
think internalizing the library would
be insecure, all the users are forced to write C wrappers or compile their
own ntfs-3g, which bosth will in effect be WAY LESS SECURE, because of the
very reasons you are trying to avoid:
1) People will inexperiencedly "make it work". They are mostly worse than
you at keeping things secure. You can tell yourself that it wasn't you,
but it was you who made the people fix the problem you created by shipping
a broken ntfs-3g.
2) Homebuild ntfs-3g versions aren't updated with the system, leaving the
system to be vulnerable after fuse's bugs are patched in the repository.
3) Wrappers will tear holes because they cause security checks in ntfs-3g
to be skipped, and they will possibly tear open all the holes you are
also trying to keep shut.
Here is my suid wrapper, just to eliminate any doubt that YOUR
NON-SOLUTION of this bug WILL CREATE SECURITY RISKS for every user:
#include
#include
int main(int argc, char* argv[]){
char* prog = malloc(strlen(argv[0])+5);
strcpy(prog, argv[0]);
strcat(prog, ".bin");
int uid=geteuid();
setuid(uid);
execvp(prog, argv);
exit(127);
}
I'd bet you can find a security risk there besides the fact that it
eliminates the ntfs-3g security checks and alters the defaults.
PS: I don't have any USB drives in /etc/fstab.
My version of Debian:
deb cdrom:[Debian GNU/Linux 7.3.0 _Wheezy_ - Official amd64 NETINST
Binary-1 20131215-04:55]/ wheezy main
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#665274: perl-base: $utf8string ~= /regex/ fails
Package: perl-base Version: 5.10.1-17squeeze3 Severity: important Tags: upstream Some versions of perl, including 5.10.1-17squeeze3, have problems matching utf-8 characters: $ LANG=en_US.UTF-8 perl -e 'use utf8; "Herbert Grönemeyer" =~ /(.*?)\s*\(with (.*)\)$/i' Malformed UTF-8 character (unexpected continuation byte 0xb6, with no preceding start byte) in pattern match (m//) at -e line 1. $ _ More info can be found at e.g. http://www.perlmonks.org/?node_id=843208 -- System Information: Debian Release: 6.0.4 APT prefers stable APT policy: (700, 'stable'), (450, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages perl-base depends on: ii dpkg 1.15.8.12 Debian package management system ii libc6 2.11.3-2 Embedded GNU C Library: Shared lib perl-base recommends no packages. Versions of packages perl-base suggests: ii perl 5.10.1-17squeeze3 Larry Wall's Practical Extraction -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#792030: systemd does not reliably mount nfs shares
On Fri, 10 Jul 2015, Michael Biebl wrote: > Am 10.07.2015 um 14:05 schrieb Bodo Eggert: > > Package: systemd > > Version: 215-17+deb8u1 > > Severity: normal > > > > Dear Maintainer, > > > > when I boot my system, some of the NFS shares don't get mounted reliably. > > > > At first I blamed it on the RPC race condition, but since I applied the > > countermeasure from gentoo linux and since only some shares are affected, > > I don't think so anymore. > > > > Also I put "/sbin/mount -a -t nfs" into /etc/rc.local, but that didn't help > > either. I guess _that_ is the rpc race condition? > > > > Today, be5:/mnt/HD/HD_a2/7eggert was affected. > > > > --- grep nfs /etc/fstab --- > > be1:/var/mail/mnt/mail nfs soft 0 0 > > be5:/mnt/HD/HD_b2/d1/mnt/nas5a nfs soft 0 0 > > be5:/mnt/HD/HD_a2/d2/mnt/nas5b nfs soft 0 0 > > be5:/mnt/HD/HD_a2/7eggert /home/7eggert/nas nfs soft 0 0 > > be5:/mnt/HD/HD_b2/nfsroot /mnt/nfsrootnfs soft 0 0 > > --- > > How do you configure your network connection? Please include specifics > like configuration files etc. > It's either the network configuration not providing > network-online.target correctly or rpcbind/nfs-common not starting up > properly. > > For the latter, can you attach the output of > systemctl status nfs-common.service rpcbind.service > See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775542#114 Maybe I can see a reason: When I look at "systemctl status", I see: --- systemctl status --- │ ├─mnt-nas5a.mount │ │ └─759 rpc.statd --no-notify --- I guess rpc.statd is only bound to the first nfs share that happens to be started (in my case chosen at random). All other nfs shares will start in parallel and race for statd. (I'd expect something like mnt-nfs3 to exist instead and all the nfs3 mounts to depend on that. It should be native to systemd, IMO ...) ## --- /etc/interfaces --- auto lo br0 iface lo inet loopback iface br0 inet static bridge_ports eth0 qemu-7eggert bridge_maxwait 0 address 192.168.7.210 netmask 255.255.255.0 gateway 192.168.7.202 pre-up tunctl -t qemu-7eggert -u 7eggert post-up ip addr add 192.168.1.210/24 dev br0 #(unused for nfs) --- ● nfs-common.service - LSB: NFS support files common to client and server Loaded: loaded (/etc/init.d/nfs-common) Active: active (running) since Sun 2015-07-12 11:23:51 CEST; 15min ago Process: 723 ExecStart=/etc/init.d/nfs-common start (code=exited, status=0/SUCCESS) CGroup: /system.slice/nfs-common.service ├─746 /sbin/rpc.statd ├─762 /sbin/sm-notify └─773 /usr/sbin/rpc.idmapd ● rpcbind.service - LSB: RPC portmapper replacement Loaded: loaded (/etc/init.d/rpcbind) Drop-In: /run/systemd/generator/rpcbind.service.d └─50-rpcbind-$portmap.conf Active: active (running) since Sun 2015-07-12 11:23:50 CEST; 15min ago Process: 691 ExecStart=/etc/init.d/rpcbind start (code=exited, status=0/SUCCESS) CGroup: /system.slice/rpcbind.service └─704 /sbin/rpcbind -w ● bind9.service - BIND Domain Name Server Loaded: loaded (/lib/systemd/system/bind9.service; enabled) Drop-In: /run/systemd/generator/bind9.service.d └─50-insserv.conf-$named.conf Active: active (running) since Sun 2015-07-12 11:24:00 CEST; 54min ago Docs: man:named(8) Main PID: 897 (named) CGroup: /system.slice/bind9.service └─897 /usr/sbin/named -f -u bind
Bug#534221: (no subject)
Reported upstream as Bug 952945 https://bugzilla.mozilla.org/show_bug.cgi?id=952945 My ¢¢: If I select the tabs to stay opened, the list of opened tabs obviously should not be cleared.
Bug#789427: debian-installer: debian installer mkfs.ext3 hangs while formatting a new partition
Package: debian-installer Severity: normal Dear Maintainer, the mkfs.ext3 program will check for DOS disklabels before formating. Creating an extended partition and then deciding to replace it with a primary partition causes the new partition to have one. Therefore the installation stopped when the question weather to proceed was to be asked. I had to manually create the filesystem in the console. -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#789475: udhcpc: valid rfc1123 hostname recognized as "bad"
Package: busybox Version: 1:1.22.0-9+deb8u1 Severity: normal Tags: d-i Dear Maintainer, The valid hostname "52-54-0-12-34-56" is recognized as bad while it should be valid according to rfc1123 (Section 2.1). - Capture of the DHCP reply: be1.lrz.bootps > 192.168.7.107.bootpc: BOOTP/DHCP, Reply, length 300, xid 0x4cc35164, Flags [none] Client-IP 192.168.7.107 Your-IP 192.168.7.107 Client-Ethernet-Address 52:54:00:12:34:56 (oui Unknown) file "be1" Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: ACK Server-ID Option 54, length 4: be1.lrz Lease-Time Option 51, length 4: 600 Subnet-Mask Option 1, length 4: 255.255.255.0 Default-Gateway Option 3, length 4: be2.lrz Domain-Name-Server Option 6, length 4: be1.lrz Hostname Option 12, length 16: "52-54-0-12-34-56" Domain-Name Option 15, length 3: "lrz" -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages busybox depends on: ii libc6 2.19-18 busybox recommends no packages. busybox suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#789475: udhcpc: valid rfc1123 hostname recognized as "bad"
On Sun, 21 Jun 2015, Geert Stappers wrote: > Control: tag -1 moreinfo > On Sun, Jun 21, 2015 at 02:14:17PM +0200, Bodo Eggert wrote: > > The valid hostname "52-54-0-12-34-56" is recognized as bad > > while it should be valid according to rfc1123 (Section 2.1). > > What programma and/or device did recognize "52-54-0-12-34-56" as bad? udhcpc, which is part of busybox > How was the error encountered? Any error messages? The debian installer will use the hostname "bad", because that's what it's told by udhcpc. > Please elaborate what the reason for this bugreport is. busybox/udhcpc should recognize this hostname as being valid since it conforms to current network standards (I cheked it). The old standard did disallow a number in the first character. > > Capture of the DHCP reply: > > be1.lrz.bootps > 192.168.7.107.bootpc: BOOTP/DHCP, Reply, length 300, > > xid 0x4cc35164, Flags [none] > > Vendor-rfc1048 Extensions > > DHCP-Message Option 53, length 1: ACK > > Hostname Option 12, length 16: "52-54-0-12-34-56" > > That is content from a network packet sent by a DHCP server, > which might be configured for providing such hostname. Yes, that's my dhcp server. I figured knowing the DHCP reply might help. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743566: [Pkg-mc-devel] Bug#743566: mc: Failed gpm connect attempt
This bug just crashed my system by generating 2.2 GB of logs and caused a day of debugging - exactly when I needed to leave for a week.
