Bug#305451: approx: runs as root
On Wednesday 20 April 2005 08:10 pm, Charles Lepple wrote: Heh. Maybe you could borrow the aptproxy userid. Why not just add another? Actually, along these lines, I wonder if there's a precedent for conflicting with another package with a server that binds to the same port. After all, the default for both apt-proxy and approx is to listen on port . (Of course, you can always reconfigure one or the other to listen on a different port, whereas most other conflicts arise from two packages that have staked out the same portion of the filesystem namespace.) That was actually one of my silent gripes, if you will. It really should bind to another port by default, like, say, 9998. Both are by no means standard port numbers, so why create conflict? pgpI1lvrL9Ny1.pgp Description: PGP signature
Bug#305451: approx: runs as root
On Thu, Apr 21, 2005 at 08:50:33AM -0700, Alexander Hvostov wrote: On Wednesday 20 April 2005 08:10 pm, Charles Lepple wrote: Heh. Maybe you could borrow the aptproxy userid. Why not just add another? Actually, along these lines, I wonder if there's a precedent for conflicting with another package with a server that binds to the same port. After all, the default for both apt-proxy and approx is to listen on port . (Of course, you can always reconfigure one or the other to listen on a different port, whereas most other conflicts arise from two packages that have staked out the same portion of the filesystem namespace.) That was actually one of my silent gripes, if you will. It really should bind to another port by default, like, say, 9998. Both are by no means standard port numbers, so why create conflict? Because many approx users are likely to be apt-proxy users, and have lines like deb http://foo:/...; in sources.list files on multiple client machines. If the default isn't , you have to track down all those files and edit them, but if it's , it's a drop in replacement. I've just posted a message on debian-devel asking for advice on whether to make the packages conflict for this reason. -- Eric Cooper e c c @ c m u . e d u -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#305451: approx: runs as root
It would be nice if approx ran as an unprivileged user. From what I can tell, it doesn't need root privileges (even to bind the listening socket). You're right, and another user also made the same suggestion, so I plan to do that. Do you have any advice on which user/group to use? I couldn't find a place in the Policy docs that spelled this out. Should I try to create a new approx user/group, which would require the base-passwd maintainer's agreement, or to reuse something else like daemon or www-data? Otherwise, this program is a welcome change from apt-proxy. Performance seems *way* better, even after I imported my entire apt-proxy cache into /var/cache/approx. Thanks for the feedback! -- Eric Cooper e c c @ c m u . e d u -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#305451: approx: runs as root
Eric Cooper said: It would be nice if approx ran as an unprivileged user. From what I can tell, it doesn't need root privileges (even to bind the listening socket). You're right, and another user also made the same suggestion, so I plan to do that. Do you have any advice on which user/group to use? Heh. Maybe you could borrow the aptproxy userid. Actually, along these lines, I wonder if there's a precedent for conflicting with another package with a server that binds to the same port. After all, the default for both apt-proxy and approx is to listen on port . (Of course, you can always reconfigure one or the other to listen on a different port, whereas most other conflicts arise from two packages that have staked out the same portion of the filesystem namespace.) Even if you had both listening to the same port, they keep databases in different subdirectories of /var. Sharing the same userid wouldn't be so much of a technical challenge as a political question. But IANADD :-) I couldn't find a place in the Policy docs that spelled this out. Should I try to create a new approx user/group, which would require the base-passwd maintainer's agreement, or to reuse something else like daemon or www-data? that's probably a question for the debian-devel list (if it hasn't been covered before). -- Charles Lepple
Bug#305451: approx: runs as root
Package: approx Version: 1.09 Severity: wishlist It would be nice if approx ran as an unprivileged user. From what I can tell, it doesn't need root privileges (even to bind the listening socket). Otherwise, this program is a welcome change from apt-proxy. Performance seems *way* better, even after I imported my entire apt-proxy cache into /var/cache/approx. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: powerpc (ppc) Kernel: Linux 2.6.10-powerpc Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages approx depends on: ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an ii libcurl37.13.2-2 Multi-protocol file transfer libra ii libidn110.5.13-1.0 GNU libidn library, implementation ii libpcre35.0-1Perl 5 Compatible Regular Expressi ii libssl0.9.7 0.9.7e-3 SSL shared libraries ii zlib1g 1:1.2.2-4compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
