RE: In what way is /cygdrive special WRT to permissions?
One final note on this: At Jeremy's suggestion, I tried changing the way /cygdrive is mounted. As Administrator I changed /etc/fstab to read //vega/repository /repos smbfs binary,noacl 0 0 none /cygdrive cygdrive binary,noacl,user 0 0 Mount now shows administra...@taurus ~ $ mount //vega/repository on /repos type smbfs (binary,noacl) C:/cygwin/bin on /usr/bin type ntfs (binary,auto) C:/cygwin/lib on /usr/lib type ntfs (binary,auto) C:/cygwin on / type ntfs (binary,auto) C: on /cygdrive/c type ntfs (binary,noacl,posix=0,user,noumount,auto) D: on /cygdrive/d type iso9660 (binary,noacl,posix=0,user,noumount,auto) F: on /cygdrive/f type smbfs (binary,noacl,posix=0,user,noumount,auto) H: on /cygdrive/h type smbfs (binary,noacl,posix=0,user,noumount,auto) Note that all drives now seem to inherit noacl from the mount of /cygdrive which for C: may not be what you want either. An ls -l of /cygrive/f now shows administra...@taurus ~ $ ls -l /cygdrive/f total 2048 drwxr-xr-x 36 Administrator None 0 2010-10-07 12:35 builds drwxr-xr-x 17 Administrator None 0 2010-10-04 18:23 releases and testing the ability to write you have administra...@taurus ~ $ test -w /cygdrive/f/builds && echo you can write you can write This was always the case when you have Administrator privileges. But, when logged in as user build which does not have Administrator privileges, you now have: $ ls -l /cygdrive/f total 2048 drwxr-xr-x 36 build None 0 2010-10-07 12:35 builds drwxr-xr-x 17 build None 0 2010-10-04 18:23 releases and $ test -w /cygdrive/f/builds && echo You can write You can write Which is the way cygwin 1.5 behaved! Perhaps the default mounting of file systems that are not NTFS should be with noacl, but that is a question best answered by more knowledgeable people. It would at least make the behavior of test consistent which what you can actually do with the filesystem. > > Corinna - > > Thanks for the reply and clarification. I have made the obvious change in > my mounts to get around this problem. However, there has been a change > in behavior between 1.5 and 1.7. I have 1.7.7 installed on Windows > Server 2003 SP2. > > The mount table shows > > $ mount > //vega/repository on /repos type smbfs (binary,noacl) > C:/cygwin/bin on /usr/bin type ntfs (binary,auto) > C:/cygwin/lib on /usr/lib type ntfs (binary,auto) > C:/cygwin on / type ntfs (binary,auto) > C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) > D: on /cygdrive/d type iso9660 (binary,posix=0,user,noumount,auto) > F: on /cygdrive/f type smbfs (binary,posix=0,user,noumount,auto) > H: on /cygdrive/h type smbfs (binary,posix=0,user,noumount,auto) > > F: also happens to be mapped to //vega/repository via the normal Windows > mechanisms. > > When signed on to the Administrator account you have: > > administra...@taurus ~ > $ ls -l /repos > total 2048 > drwxr-xr-x 36 Administrator None 0 2010-10-04 19:30 builds > drwxr-xr-x 17 Administrator None 0 2010-10-04 18:23 releases > > administra...@taurus ~ > $ test -w /repos/builds && echo writeable > writeable > > administra...@taurus ~ > $ ls -l /cygdrive/f > total 2048 > drwxrwxr-x 36 0 2010-10-04 19:30 builds > drwxrwxr-x 17 0 2010-10-04 18:23 releases > > administra...@taurus ~ > $ test -w /repos/builds && echo writeable > writeable > > When logged on as the non-admistrative user build you have: > > bu...@taurus ~ > $ ls -l /repos > total 2048 > drwxr-xr-x 36 build None 0 2010-10-04 19:30 builds > drwxr-xr-x 17 build None 0 2010-10-04 18:23 releases > > bu...@taurus ~ > $ test -w /repos/builds && echo writeable > writeable > > bu...@taurus ~ > $ ls -l /cygdrive/f > total 2048 > drwxrwxr-x 36 0 2010-10-04 19:30 builds > drwxrwxr-x 17 0 2010-10-04 18:23 releases > > bu...@taurus ~ > $ test -w /cygdrive/f/builds && echo writeable > > bu...@taurus ~ > $ echo test >/cygdrive/f/builds/zap > > bu...@taurus ~ > $ ls -l /cygdrive/f/builds/zap > -rwxrwxr-x 1 5 2010-10-06 16:11 /cygdrive/f/builds/zap > > Notice that the test -w /cygdrive/f/builds reports that /cygdrive/f/builds > is not writeable, yet you can create and write files in > /cygdrive/f/builds! > THIS IS INCONSTENT BEHAVIOR. Cygwin 1.5 did not have this behavior. > > Regarding the mount of drive letters via /etc/fstab. I am not sure what > the documentation should say about this. Overriding the default mount of > a single drive letter in fstab actually seems to work, although it simply > reproduces the same behavior as the default. > > Even if I understood the actual behavior, I regret that am not familiar > with the ways of Cygwin source maintenance to make the documentation > changes. I have to leave this to somebody else more qualified. > > Cheers, Andy > > > > On Oct 6 1:48 Corinna Vischen wrote: > > > > > > On Oct 5 15:40, Andy Hall wrote: > > > If instead, I map F: to /cygdrive/c with the following entry in > > /e
Re: In what way is /cygdrive special WRT to permissions?
On 10/6/2010 4:38 PM, Andy Hall wrote: > There is no doubt that this behavior changed from 1.5 to 1.7. The instant I > upgraded from 1.5 to 1.7.7, build scripts that test for the abilty to write > to the directories in F: instantly started reporting the directories were > not writeable using test -w, yet you can still create and write files via > Cygwin. > The explict mounting of //vega/repository is the workaround I eventually > settled on. At the risk of taking this thread a little off topic, why do your build scripts explicitly check for write access to these directories? I agree that it would be good to keep this working in order to maintain compatibility with older Cygwin releases, but the build scripts we use where I work don't bother to check for access to things before using them. They just assume that they have the necessary access and then fail with an explicit error when those assumptions are faulty. I also always considered the check before you use methodology to be a bit risky to begin with. The reason being that between the time you check for access and the time you try to actually use that access another process could remove the access or even the entire resource. At that point you fail as if you never bothered to check for access in the first place, so your logic had better be able to deal with that somehow. If you're going to have logic to handle failed access attempts, you may as well abandon the access checks. :-) -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: In what way is /cygdrive special WRT to permissions?
There is no doubt that this behavior changed from 1.5 to 1.7. The instant I upgraded from 1.5 to 1.7.7, build scripts that test for the abilty to write to the directories in F: instantly started reporting the directories were not writeable using test -w, yet you can still create and write files via Cygwin. Furthermore, the user build can also create files and directories in F: using windows, so the OS apparently thinks the user build has these access rights as well. Is it possible that test -w may have a bug? The thing that is weird is that the explicit mount of //vega/repository on /repos with noacl has the the desireable effect. It you log in as Administrator the files appear to be owned by Administrator and if you log in as build, the files appear to be owned by build. I would assume this is the result of "guessing" the permissions when noacl is used. The explict mounting of //vega/repository is the workaround I eventually settled on. Andy > On Oct 6 12:43, Corinna Vischen wrote: > On Oct 6 13:19, Andy Hall wrote: > > Notice that the test -w /cygdrive/f/builds reports that > /cygdrive/f/builds > > is not writeable, yet you can create and write files in > /cygdrive/f/builds! > > THIS IS INCONSTENT BEHAVIOR. Cygwin 1.5 did not have this behavior. > > I somehow doubt that. I'm just not sure if I can explain that > correctly, given how tired I am. The difference is that under 1.5 all > smb drives were by default mounted with "noacl", aka > "CYGWIN=nosmbntsec". So all permissions were just faked and Cygwin's > access call was more or less a wild guess. With a drive mounted with > "acl" the OS (yes, Windows itself) is asked if the current user has > write permissions, based on the current user token and the ACL of the > file. Apparently "non writable" is what you get here, because the ACL > returned by the Samba drive only contains the ACEs for the Linux user and > group, not for your current Windows user and group. You can add these > Linux user's and groups to your local passwd and group file (see > http://cygwin.com/cygwin-ug-net/using-utils.html#mkpasswd and > http://cygwin.com/cygwin-ug-net/using-utils.html#mkgroup), but it won't > change what the OS returns in the access check. I'm sorry, this bugs > me for years, but there nothing Cygwin can do about this. Nor can Samba > do anything. Yes, I asked on the samba developer mailing list at one > point... > > The fact that the admin can write is normal, too, since admins (those > not restricted by UAC) always have write permissions under Cygwin 1.7.7, > just like a root user under Linux. That's probably even documented > somewhere, I just don't recall where. > > > Corinna > > -- > Corinna Vinschen Please, send mails regarding Cygwin to > Cygwin Project Co-Leader cygwin AT cygwin DOT com > Red Hat > > -- > Problem reports: http://cygwin.com/problems.html > FAQ: http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: In what way is /cygdrive special WRT to permissions?
On 10/06/2010 04:42 PM, Corinna Vinschen wrote: > On Oct 6 13:19, Andy Hall wrote: >> Notice that the test -w /cygdrive/f/builds reports that /cygdrive/f/builds >> is not writeable, yet you can create and write files in /cygdrive/f/builds! >> THIS IS INCONSTENT BEHAVIOR. Cygwin 1.5 did not have this behavior. > > I somehow doubt that. I'm just not sure if I can explain that > correctly, given how tired I am. The difference is that under 1.5 all > smb drives were by default mounted with "noacl", aka > "CYGWIN=nosmbntsec". So all permissions were just faked and Cygwin's > access call was more or less a wild guess. With a drive mounted with > "acl" the OS (yes, Windows itself) is asked if the current user has > write permissions, based on the current user token and the ACL of the > file. Apparently "non writable" is what you get here, because the ACL > returned by the Samba drive only contains the ACEs for the Linux user and > group, not for your current Windows user and group. You can add these > Linux user's and groups to your local passwd and group file (see > http://cygwin.com/cygwin-ug-net/using-utils.html#mkpasswd and > http://cygwin.com/cygwin-ug-net/using-utils.html#mkgroup), but it won't > change what the OS returns in the access check. I'm sorry, this bugs > me for years, but there nothing Cygwin can do about this. Nor can Samba > do anything. Yes, I asked on the samba developer mailing list at one > point... Note that not only can you not trust the acl's as per Corinna's message above when in acl mode, you also can't trust the write bit for directories in the noacl mode, because samba uses the FAT read-only bit to provide this information, but Windows and Cygwin do not. See this thread: http://cygwin.com/ml/cygwin/2010-01/msg00222.html Basically, AFAICT, smbfs permissions are broken, though I suspect if everything is running in a Windows Domain, with smbfs in acl mode, things would work ok. Cheers, Raman -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: In what way is /cygdrive special WRT to permissions?
On Oct 6 13:19, Andy Hall wrote: > Notice that the test -w /cygdrive/f/builds reports that /cygdrive/f/builds > is not writeable, yet you can create and write files in /cygdrive/f/builds! > THIS IS INCONSTENT BEHAVIOR. Cygwin 1.5 did not have this behavior. I somehow doubt that. I'm just not sure if I can explain that correctly, given how tired I am. The difference is that under 1.5 all smb drives were by default mounted with "noacl", aka "CYGWIN=nosmbntsec". So all permissions were just faked and Cygwin's access call was more or less a wild guess. With a drive mounted with "acl" the OS (yes, Windows itself) is asked if the current user has write permissions, based on the current user token and the ACL of the file. Apparently "non writable" is what you get here, because the ACL returned by the Samba drive only contains the ACEs for the Linux user and group, not for your current Windows user and group. You can add these Linux user's and groups to your local passwd and group file (see http://cygwin.com/cygwin-ug-net/using-utils.html#mkpasswd and http://cygwin.com/cygwin-ug-net/using-utils.html#mkgroup), but it won't change what the OS returns in the access check. I'm sorry, this bugs me for years, but there nothing Cygwin can do about this. Nor can Samba do anything. Yes, I asked on the samba developer mailing list at one point... The fact that the admin can write is normal, too, since admins (those not restricted by UAC) always have write permissions under Cygwin 1.7.7, just like a root user under Linux. That's probably even documented somewhere, I just don't recall where. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: In what way is /cygdrive special WRT to permissions?
Corinna - Thanks for the reply and clarification. I have made the obvious change in my mounts to get around this problem. However, there has been a change in behavior between 1.5 and 1.7. I have 1.7.7 installed on Windows Server 2003 SP2. The mount table shows $ mount //vega/repository on /repos type smbfs (binary,noacl) C:/cygwin/bin on /usr/bin type ntfs (binary,auto) C:/cygwin/lib on /usr/lib type ntfs (binary,auto) C:/cygwin on / type ntfs (binary,auto) C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) D: on /cygdrive/d type iso9660 (binary,posix=0,user,noumount,auto) F: on /cygdrive/f type smbfs (binary,posix=0,user,noumount,auto) H: on /cygdrive/h type smbfs (binary,posix=0,user,noumount,auto) F: also happens to be mapped to //vega/repository via the normal Windows mechanisms. When signed on to the Administrator account you have: administra...@taurus ~ $ ls -l /repos total 2048 drwxr-xr-x 36 Administrator None 0 2010-10-04 19:30 builds drwxr-xr-x 17 Administrator None 0 2010-10-04 18:23 releases administra...@taurus ~ $ test -w /repos/builds && echo writeable writeable administra...@taurus ~ $ ls -l /cygdrive/f total 2048 drwxrwxr-x 36 0 2010-10-04 19:30 builds drwxrwxr-x 17 0 2010-10-04 18:23 releases administra...@taurus ~ $ test -w /repos/builds && echo writeable Writeable When logged on as the non-admistrative user build you have: bu...@taurus ~ $ ls -l /repos total 2048 drwxr-xr-x 36 build None 0 2010-10-04 19:30 builds drwxr-xr-x 17 build None 0 2010-10-04 18:23 releases bu...@taurus ~ $ test -w /repos/builds && echo writeable writeable bu...@taurus ~ $ ls -l /cygdrive/f total 2048 drwxrwxr-x 36 0 2010-10-04 19:30 builds drwxrwxr-x 17 0 2010-10-04 18:23 releases bu...@taurus ~ $ test -w /cygdrive/f/builds && echo writeable bu...@taurus ~ $ echo test >/cygdrive/f/builds/zap bu...@taurus ~ $ ls -l /cygdrive/f/builds/zap -rwxrwxr-x 1 5 2010-10-06 16:11 /cygdrive/f/builds/zap Notice that the test -w /cygdrive/f/builds reports that /cygdrive/f/builds is not writeable, yet you can create and write files in /cygdrive/f/builds! THIS IS INCONSTENT BEHAVIOR. Cygwin 1.5 did not have this behavior. Regarding the mount of drive letters via /etc/fstab. I am not sure what the documentation should say about this. Overriding the default mount of a single drive letter in fstab actually seems to work, although it simply reproduces the same behavior as the default. Even if I understood the actual behavior, I regret that am not familiar with the ways of Cygwin source maintenance to make the documentation changes. I have to leave this to somebody else more qualified. Cheers, Andy > On Oct 6 1:48 Corinna Vischen wrote: > > > On Oct 5 15:40, Andy Hall wrote: > > If instead, I map F: to /cygdrive/c with the following entry in > /etc/fstab > > > > F: /cygdrive/f smbfs binary,noacl 0 0 > > > > mount shows > > > > $ mount > > C:/cygwin/bin on /usr/bin type ntfs (binary,auto) > > C:/cygwin/lib on /usr/lib type ntfs (binary,auto) > > C:/cygwin on / type ntfs (binary,auto) > > F: on /cygdrive/f type smbfs (binary,noacl) > > C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) > > > > And ls -l of /cygdrive/f shows > > > > $ ls -l /cygdrive/f > > total 2048 > > drwxrwxr-x 36 0 2010-10-04 16:30 builds > > drwxrwxr-x 17 0 2010-10-04 15:23 releases > > [...] > > Why am I getting -1 for the uid and gid when I mount to /cygdrive/f but > not > > to /repos1? > > That's a restriction of the cygdrive prefix handling. You can't > override the cygdrive mount options for a single drive. It's an > all or nothing thingy. I guess it would help to refuse such paths > in /etc/fstab or mount(1), or at least improve the documentation, > but, well, http://cygwin.com/acronyms/#SHTDI. > > > Corinna > > -- > Corinna Vinschen Please, send mails regarding Cygwin to > Cygwin Project Co-Leader cygwin AT cygwin DOT com > Red Hat > > -- > Problem reports: http://cygwin.com/problems.html > FAQ: http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: In what way is /cygdrive special WRT to permissions?
On Oct 5 15:40, Andy Hall wrote: > If instead, I map F: to /cygdrive/c with the following entry in /etc/fstab > > F: /cygdrive/f smbfs binary,noacl 0 0 > > mount shows > > $ mount > C:/cygwin/bin on /usr/bin type ntfs (binary,auto) > C:/cygwin/lib on /usr/lib type ntfs (binary,auto) > C:/cygwin on / type ntfs (binary,auto) > F: on /cygdrive/f type smbfs (binary,noacl) > C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) > > And ls -l of /cygdrive/f shows > > $ ls -l /cygdrive/f > total 2048 > drwxrwxr-x 36 0 2010-10-04 16:30 builds > drwxrwxr-x 17 0 2010-10-04 15:23 releases > [...] > Why am I getting -1 for the uid and gid when I mount to /cygdrive/f but not > to /repos1? That's a restriction of the cygdrive prefix handling. You can't override the cygdrive mount options for a single drive. It's an all or nothing thingy. I guess it would help to refuse such paths in /etc/fstab or mount(1), or at least improve the documentation, but, well, http://cygwin.com/acronyms/#SHTDI. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
