From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27719 invoked by alias); 10 Nov 2014 20:52:20 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 27704 invoked by uid 89); 10 Nov 2014 20:52:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: calimero.vinschen.de Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 10 Nov 2014 20:52:19 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id D00388E12EE; Mon, 10 Nov 2014 21:52:16 +0100 (CET) Date: Mon, 10 Nov 2014 20:52:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: RFC: 1.7.33 problem with user's home directory Message-ID: <20141110205216.GJ2782@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="C7PTD44AewjTsiSV" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2014-11/txt/msg00195.txt.bz2 --C7PTD44AewjTsiSV Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2391 Hi, after a long discussion in RL today, I came to the conclusion that there's a major problem in the current handling of the user's home directory in AD environments in the new user account code when not using /etc/passwd files. Here's how it works and how it's documented in the preliminary documentation at https://cygwin.com/preliminary-ug/ntsec.html#ntsec-mapping-passwdinfo - If your account is an AD account, the home directory is taken from the RFC 2307 entry unixHomeDirectory. - Otherwise, if these values are empty or don't exist, your fallback home directory is /home/$USER (without domain prefix). As you may have noticed, there's nothing in there taking the Windows home directory into account. It's indeed not used at all by the new code. Up to Cygwin 1.7.32, mkpasswd (but not with -u) generated the Cygwin home directory by converting the SAM/AD home folder entry to POSIX style, if it's non-empty. Fallback is /home/$USER. When I implemented the new scheme I thought it a good idea to decouple the Cygwin home dir from the Windows home dir. However, in the today's discussion the following two arguments came up: - If you're using the Windows home folder setting to maintain file server based home directories, you typically want that these directories are used for Cygwin stuff as well (central administration, central backup). Having to maintain the home directories twice, once in the homeDirectory, once in the unixHomeDirectory entry is quite a hassle, especially given that unixHomeDirectory does not support variable substitution (e.g. "/home/%USERNAME%" won't work). - If you're already using AD as NIS server, unixHomeDirectory is already used for UNIX machines. Trying to align the unixHomeDirectory for Cygwin to homeDirectory for all the rest of Windows will potentially become impossible then. These arguments are quite serious and it questions the "good idea" part of this change a lot. What do you think? Shall the "db" entries utilize the Windows home folder if it exits(*) and drop using the unixHomeDirectory? It seems inevitable... Corinna (*) This would automatically work for SAM accounts as well because SAM provides the same Windows home folder entry. --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --C7PTD44AewjTsiSV Content-Type: application/pgp-signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUYSWAAAoJEPU2Bp2uRE+gaPMP/jl3U+ztPSsaSmALzf264uqx InEYtVVvXfsQAtQqylI0bTQko8AJ6TSckA9sVRPy7cSbenk6d6dsLUEPTi8FD3n1 PGwQfcv0VRdAWD0bj78OhR9We4CE/IWMRu7aIUKg4ko8ANI1yMHvMxnQVqqYWhEJ xGQCtG4VOEJBBjcAMXt+nVSiHyDQ3ysp+rRpUhpCQ2rxs609sMj8jT5TQqBIC4/5 ihqc1Phd4OM3QiIWn+6OWgfZL/t1GiScTbrnclA31R9sbpyTJUhaGdR/t01G+XZV SQKL+mJqcmbLNEDyml40zC9mQSOy0aosHlHmVDaoxyCfB8IOZcqF2mzQw0Cx0tcT wZEpyGwVzso0KOeg+7ysRWrtaBUOS0cwm/zcpTa2uOVceupBiMotdcNjJksiFqya l1Nor5uZHmqjExnyZRqOPGzX+QPLCYqRzGvV4JrThyFNFjecuM2cjz3QOS7WV/iZ Q++9eJtwC+xivau/zkPe2+8wWTAOIwgbjfL2DgrGB6FPJwhVHequeRFviS3EprGU g56oUPoKkTG6DzY2E74nSAEHezU6PUMc3VZa5rJDfYNircrNN/ZXZZ4+LgpKdb/g B9KE5rRoDVPmMdyrk/me5Jzua2P6eGclwbUFCghEbkiHvX3kMljIl/hkbMnF/a3b qJ3XPER1DqYMd5OADzyq =mQp0 -----END PGP SIGNATURE----- --C7PTD44AewjTsiSV--