Charles Wilson wrote: > > Vista + UAC + cygwin seems a bit...flaky. Yep.
I moved my old cygwin-1.7 installation and reinstalled. This time, I did nothing special -- I did /not/ prepare the C:\cygwin-1.7 directory in advance (e.g. create the directory and then edit its security settings). This is on Vista, with UAC enabled. I ran setup-1.7 as Administrator (while logged in to my normal user account, which is not a member of the Administrators group). I got the privilege elevation prompt, and typed in the password. The installation seemed to go fine. However, when I launched cygwin as my normal self, I got some errors from my .bashrc: bash: cannot create temp file for here document: Permission denied rm: cannot remove `/c/Users/self/.keychain/mymachine-lockf': Permission denied Here are some relevant perms: $ ls -l / total 526K ----r-x---+ 1 Administrator Users 61 Aug 15 17:16 Cygwin.bat* ----r-x---+ 1 Administrator Users 6.9K Aug 15 18:11 Cygwin.ico* d---r-x---+ 1 Administrator Users 384K Aug 15 17:55 bin/ d---------+ 1 ???????? ???????? 20K Aug 15 17:14 c/ d--x--x--x 4 self None 0 Nov 30 2006 cygdrive/ drwxr-xr-x+ 1 self None 16K Aug 15 16:14 desktop/ drwxrwxr-x+ 1 Administrator Users 0 Aug 15 17:16 dev/ drwxrwxr-x+ 1 Administrator Users 8.0K Aug 15 17:55 etc/ d---r-x---+ 1 Administrator Users 80K Aug 15 17:55 lib/ drwx------+ 1 self None 4.0K May 24 00:20 mydocs/ dr-xr-xr-x 12 self None 0 Nov 30 2006 proc/ d---r-x---+ 1 Administrator Users 0 Aug 15 17:52 sbin/ lrwxrwxrwx 1 Administrator Users 17 Aug 15 17:16 terminfo -> ../share/terminfo drwxrwxrwt+ 1 Administrator Users 0 Aug 15 18:13 tmp/ d---r-x---+ 1 Administrator Users 4.0K Aug 15 17:54 usr/ d---r-x---+ 1 Administrator Users 0 Aug 15 17:16 var/ (the terminfo symlink is, I think, because the terminfo postinstall script is running before the fstab is created, but that's just a guess, and isn't what I'm concerned about here) $ ls -l /etc total 541K -rw-rw-rw- 1 Administrator Users 4.4K Aug 15 17:16 DIR_COLORS d---r-x---+ 1 Administrator Users 4.0K Aug 15 17:53 X11/ d---r-x---+ 1 Administrator Users 4.0K Aug 15 17:55 alternatives/ -rw-rw-rw- 1 Administrator None 301 Aug 15 17:16 bash.bashrc -r-xr-x--- 1 Administrator None 844 Aug 15 17:54 colordiffrc* drwxr-xr-x+ 1 Administrator None 0 Aug 15 17:54 colorgcc/ -r-xr-x--- 1 Administrator None 1.5K Aug 15 17:54 cygport.conf* d---r-x---+ 1 Administrator Users 0 Aug 15 17:15 defaults/ -r-xr-x--- 1 Administrator None 4.8K Aug 15 17:54 enscript.cfg* d---r-x---+ 1 Administrator Users 0 Aug 15 17:50 fonts/ -rw-rw-rw- 1 Administrator None 3.3K Aug 15 17:16 fstab drwxrwxrwt+ 1 Administrator None 0 Aug 15 18:13 fstab.d/ -rw-r--r--+ 1 Administrator None 14 Aug 15 17:25 ftpusers -rw-r--r--+ 1 Administrator None 40 Aug 15 17:25 ftpwelcome -rwxrwxrwx 1 Administrator Users 457 Aug 15 17:16 group* drwxrwxrwx+ 1 Administrator None 0 Aug 15 17:54 gtk-2.0/ lrwxrwxrwx 1 Administrator None 37 Aug 15 17:16 hosts -> /c/Windows/system32/drivers/etc/hosts* -r-xr-x--- 1 Administrator None 422 Aug 15 17:25 hosts.allow* -r-xr-x--- 1 Administrator None 225 Aug 15 17:25 hosts.deny* -rw-r--r--+ 1 Administrator None 2.5K Aug 15 17:25 inetd.conf drwxrwxr-x+ 1 Administrator Users 0 Aug 15 17:24 inetd.d/ -r-xr-x--- 1 Administrator None 1.7K Aug 15 17:54 inittab* -r-xr-x--- 1 Administrator None 137K Aug 15 17:55 lynx.cfg* ----r-x---+ 1 Administrator Users 123K Jul 22 11:49 moduli* -rw-r--r--+ 1 Administrator None 1.7K Aug 15 17:25 motd lrwxrwxrwx 1 Administrator None 40 Aug 15 17:16 networks -> /c/Windows/system32/drivers/etc/networks* drwxrwxrwx+ 1 Administrator Users 0 Aug 15 17:54 pango/ -rwxrwxrwx 1 Administrator Users 1.3K Aug 15 17:16 passwd* d---r-x---+ 1 Administrator Users 28K Aug 15 17:55 postinstall/ d---r-x---+ 1 Administrator Users 12K Aug 15 17:54 preremove/ -rw-rw-rw- 1 Administrator None 6.4K Aug 15 17:16 profile d---r-x---+ 1 Administrator Users 4.0K Aug 15 17:53 profile.d/ lrwxrwxrwx 1 Administrator None 40 Aug 15 17:16 protocols -> /c/Windows/system32/drivers/etc/protocol* d---r-x---+ 1 Administrator Users 4.0K Aug 15 17:54 rc.d/ lrwxrwxrwx 1 Administrator None 40 Aug 15 17:16 services -> /c/Windows/system32/drivers/etc/services* d---r-x---+ 1 Administrator Users 128K Aug 15 17:53 setup/ -rw-r--r--+ 1 Administrator None 138 Aug 15 17:25 shells d---r-x---+ 1 Administrator Users 0 Aug 15 17:16 skel/ d---r-x---+ 1 Administrator Users 0 Aug 15 17:52 ssmtp/ d---r-x---+ 1 Administrator Users 0 Aug 15 17:54 sysconfig/ -rw-r--r--+ 1 Administrator None 368 Aug 15 17:25 syslog.conf ----r-x---+ 1 Administrator Users 15K Aug 15 17:55 termcap* d---r-x---+ 1 Administrator Users 0 Aug 15 17:52 terminfo/ ----r-x---+ 1 Administrator Users 4.2K Jun 4 12:32 wgetrc* -rwxr-xr-x 1 Administrator None 298 Nov 10 2002 xinetd.conf* drwxr-xr-x+ 1 Administrator None 4.0K Nov 9 2002 xinetd.d/ $ (cd ~/.. && ls -ld *) drwxr-xr-x+ 1 SYSTEM SYSTEM 12K Jul 22 22:55 Administrator/ lrwxrwxrwx 1 SYSTEM SYSTEM 23 Nov 2 2006 All Users -> /cygdrive/c/ProgramData/ drwxr-xr-x+ 1 Administrators ???????? 8.0K Nov 2 2006 Default/ lrwxrwxrwx 1 SYSTEM SYSTEM 25 Nov 2 2006 Default User -> /cygdrive/c/Users/Default/ drwxr-xr-x 1 self None 0 Apr 26 21:43 HP_Admin/ drwx------+ 1 Administrators ???????? 4.0K Mar 18 14:31 Public/ drwxr-xr-x+ 1 SYSTEM SYSTEM 16K Aug 7 19:45 self / drwxr-xr-x 1 self None 0 Apr 25 14:51 cyg_server/ -rwxr-xr-x+ 1 SYSTEM SYSTEM 174 May 24 14:51 desktop.ini* (I have no idea why self owns the HP_Admin and cyg_server home directories. That's just bizarre). $ getfacl ~ # file: /c/Users/self # owner: SYSTEM # group: SYSTEM user::rwx user:self:rwx group::rwx group:root:rwx mask:rwx other:r-x default:user:self:rwx default:group:root:rwx default:group:SYSTEM:rwx default:mask:rwx $ getfacl /tmp # file: /tmp # owner: Administrator # group: Users user::rwx group::rwx group:root:rwx group:SYSTEM:rwx mask:rwx other:rwx default:group:root:rwx default:group:SYSTEM:rwx default:group:Users:r-x default:mask:rwx None of this seems right. The Users group does not have write access to /tmp, for one thing. SYSTEM owns my home directory, even if I do have an rwx ACL entry. And the perm bits on everything just look /wrong/. I think setup.exe on Vista should be a little more careful about the permissinos/ownership it applies to files and directories that it creates, especially under the installation scenario above -- which ought to be considered the, or one of a very few, "normal" installation scenario(s) on Vista. I do NOT think users should be expected to FIRST create their installation directory manually, then muck about with its inheritable security settings, before running setup-1.7.exe for the first time for a "virgin" install. (that's what I had to do last time, with setup-2.588) -- Chuck
