Lone in the night

This bug seems to be here from a long time. Even if a patch exists, the bug is still here in the most recent version. Here is the resolution (I assume gcc is installed): Stop your vsftpd daemon: service vsftpd stop Download the lastest source package (vsftpd-2.0.5 so far) from http://vsftpd.beasts.org . gunzip and untar # gunzip vsftpd-2.0.5.tar.gz # tar xf vsftpd-2.0.5.tar # cd vsftpd-2.0.5 A couple of files must be changed postlogin.c , line 1831 Replace ... if (p_sess->is_anonymous && tunable_chown_uploads) { vsf_sysutil_fchmod(new_file_fd, 0600); if (tunable_one_process_model) { ... by ... if (p_sess->is_anonymous && tunable_chown_uploads) { vsf_sysutil_fchmod(new_file_fd, (0666 & ~tunable_anon_umask)); if (tunable_one_process_model) { ... tunable.c , line 129,130 Replace /* -rw-rw-rw- */ unsigned int tunable_file_open_mode = 0666; by /* -rw------- */ unsigned int tunable_file_open_mode = 0600; builddefs.c , line 9 Replace ...

The goal of this document is to explain how delegating the authentication mecanism for my Linux servers on a LDAP directory. Like many of you, our architecture also includes an Windows Active Directory server for the Windows workstation. To avoid having passwords both in AD and LDAP, they are only owned by AD; LDAP only have extra-info (groups user belongs to, and so on). This curious architecture is due to the fact our AD server belongs to a forest we don't manage. In turn, we have full control on the LDAP server. The main drawback of this specific architecture is to split identification and authentication; one is done on LDAP, the other on AD. Ok, now let's open the hood ... Every user must have a posixAccount object class. This object class contains the Unix specific information. You could use several tools to create this object class; personaly, I do it with simple openldap commands, wrapped in a small script: # ldapmodify -W -x -v -h $LDAP -D $CRED -a -f /tmp/posixAccount...