Bug#581739: permission check on .forward files ignores user private groups
On Sun, May 16, 2010 at 01:24:31PM +0200, Andreas Metzler wrote: > On 2010-05-15 Andreas Hemel wrote: > > Package: exim4 > > Version: 4.71-4 > > Severity: normal > > > According to bug #581434 the default umask on new installations will > > change from 022 to 002. Debian uses user private groups, meaning every > > user is in his own private group, that nobody else is a member of. > > Hello, > This is not entirely correct. Debian uses user private groups *by* > *default* but can also be set differently. Just take a look at the > .debian.org machines, they do not use UPGs (except for alioth): > > ametz...@merkel:~$ getent passwd ametzler > ametzler:x:2571:800:Andreas Metzler:/home/ametzler:/bin/bash > ametz...@merkel:~$ getent group 800 > Debian:x:800:cvs_boot > ametz...@merkel:~$ groups > Debian I'm not a DD, so I don't have access to those machines. The possibility to disable UPG is not directly relevant to the point I was trying to make here. I'm simply arguing that something like the following should work on a Debian system by default: $ echo "m...@example.com" > ~/.forward Currently, if the umask defaults to 002, this will prevent mail delivery and the user is in no way notified that there is a problem. > I could set > > modemask = 002 > > on the userforward router and make it overrideable by macro. Since we > already set check_local_user the modemask setting switches on > check_group. Exim will require that the .forward file is owned by the > users primary group. (This could introduce breakage on upgrades if > .forward is 0600 but owned by a different group delivery will break. IMHO the ideal solution would be to determine the applicable modemask based on whether the group owning the .forward is the private group of the user. That is, the user is the only member and the group name is identical to the user name. I realize this is probably not possible without patching exim, so I'm, for my part, happy with the solution you outlined above. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#581739: permission check on .forward files ignores user private groups
Package: exim4 Version: 4.71-4 Severity: normal According to bug #581434 the default umask on new installations will change from 022 to 002. Debian uses user private groups, meaning every user is in his own private group, that nobody else is a member of. This change makes it easier to setup additional collaboration groups without the need to bug all partaking users to change their umask. For further details see #581434 and the discussion on debian-devel [1]. Exim checks the permission bits on user .forward files and refuses to deliver any mail if the .forward file is group writable. It does not check if the user is the only member in the group associated with the .forward file. In that case setting the group writable bit is save. The change of the default umask causes all .forward files created on new installs to have the group writable bit set by default. If Exim refuses to deliver mail because of this, the user is not (and probably can not be) notified and the only way to find out why mail is not deliviered is looking at the log files, to which a regular user does not have access. I've reproduced this problem with both 4.71-4 from unstable and 4.71-2~bpo50+1 from lenny-backports. With the latter version I even completly lost some system mail. I realize that bounces could not be deliviered because both the receiver and sender were essentially the same user (with the 'broken' .forward permissions), but I do not understand why these mails were dropped instead of being frozen. [1] http://lists.debian.org/debian-devel/2010/05/msg00252.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#581434: UPG and the default umask
On Fri, May 14, 2010 at 01:21:41PM -0400, Joey Hess wrote: > Vincent Danjean wrote: > > I'm happy with this move. However, there is still an interaction with ssh > > to deal with: > > > vdanj...@eyak:~$ chmod -Rv g+w .ssh/authorized_keys > > vdanj...@eyak:~$ ssh localhost > > vdanj...@localhost's password: > > And, in /var/log/auth.log: > > May 14 09:42:17 eyak sshd[1618]: Authentication refused: bad ownership or > > modes for file /home/vdanjean/.ssh/authorized_keys > > maildrop has the same problem with .mailfilter files. As does exim with .forward files. Should this be reported as a bug against exim, now that the default umask will change? Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#438556: tagpy: Fix segfault in tapgy.id3v2.Tag.addFrame()
Package: tagpy
Version: 0.91-1
Severity: normal
Tags: patch
Subject: tagpy: Fix segfault in tapgy.id3v2.Tag.addFrame()
Package: tagpy
Version: 0.91-1
Severity: important
Tags: patch
Adding a new Frame to an ID3v2 Tag reproducibly causes a segementation
fault. The TagLib documentation specifies that Tag::addFrame() takes
ownership of the pointer passed to it, but tagpy ignores this. I think
the result is that both, python and TagLib try to free() the Frame
pointer.
The crash is reproducible using the following python script:
import tagpy
import tagpy.id3v2
fileref = tagpy.FileRef('file.mp3')
file = fileref.file()
tag = file.ID3v2Tag(True)
frame = tagpy.id3v2.UniqueFileIdentifierFrame('blah', 'blah')
tag.addFrame(frame)
file.save()
According to the Boost.Python FAQ[1] the solution would be to use
std::auto_ptr. But I wasn't able to get it to work, so I worked around
using std::auto_ptr by simply cloning the Frame object before passing it
to addFrame().
Maybe somebody who is more knowledgeable in C++ than I am, can fix this
the right way.
[1] http://www.boost.org/libs/python/doc/v2/faq.html#ownership
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.22.2 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.22.2 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
--- orig/tagpy-0.91/src/id3.cpp 2006-03-21 19:08:11.0 +0100
+++ modified/tagpy-0.91/src/id3.cpp 2007-08-04 15:33:36.393646285 +0200
@@ -35,6 +35,12 @@
void id3v2_Tag_removeFrame(ID3v2::Tag &t, ID3v2::Frame *f) {
t.removeFrame(f); }
+ void id3v2_Tag_addFrame(ID3v2::Tag &t, ID3v2::Frame *f)
+ {
+ID3v2::Frame *f_clone =
ID3v2::FrameFactory::instance()->createFrame(f->render());
+t.addFrame(f_clone);
+ }
+
object id3v2_rvf_channels(const ID3v2::RelativeVolumeFrame &rvf)
{
List l = rvf.channels();
@@ -171,7 +177,7 @@
.def("frameList", fl1, return_internal_reference<>())
.def("frameList", fl2, return_internal_reference<>())
- .DEF_SIMPLE_METHOD(addFrame)
+ .def("addFrame", &id3v2_Tag_addFrame)
.DEF_SIMPLE_METHOD(removeFrame)
.DEF_SIMPLE_METHOD(removeFrames)
Bug#353259: vrms: reports blender as non-free
Package: vrms Version: 1.11 Severity: normal blender is reported as non-free, but it has been gpl'd several years ago and is now in main. -- System Information: Debian Release: testing/unstable Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14.5 Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Versions of packages vrms depends on: ii perl-modules 5.8.8-2Core Perl modules vrms recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#349003: /etc/init.d/wzdftpd stop/restart fails
Package: wzdftpd Version: 0.6.1-1 Severity: important When stopping wzdftpd with /etc/init.d/wzdftpd stop, the init script says it stopped the daemon, although it is still running. Using the init script to restart wzdftpd just starts second instance. I'm not if sure if reload works, but I think it doesn't. This seems to be caused by wzdftpd not creating a pid file on startup, the directory /var/run/wzdftpd/ stays empty. Maybe the -m flag should be passed to start-stop-daemon? Andreas -- System Information: Debian Release: testing/unstable Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14.5 Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Versions of packages wzdftpd depends on: ii debconf [debconf-2.0] 1.4.68 Debian configuration management sy ii libc6 2.3.5-12 GNU C Library: Shared libraries an ii libgcrypt11 1.2.2-1LGPL Crypto library - runtime libr ii libgnutls12 1.2.9-2the GNU TLS library - runtime libr ii libgpg-error0 1.1-4 library for common error values an ii libpam0g 0.79-3 Pluggable Authentication Modules l ii libtasn1-20.2.17-1 Manage ASN.1 structures (runtime) ii po-debconf0.9.2 manage translated Debconf template ii ucf 2.004 Update Configuration File: preserv ii zlib1g1:1.2.3-9 compression library - runtime wzdftpd recommends no packages. -- debconf information: * wzdftpd/upgrade: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
