Re: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
There we go, a proper patch. It adds two command line parameters: -f --no-acl-files -F --no-acl-dirs I could not figure if that's possible to share single variable between two source files, so I just used two variables. At least it works as intended and covers every situation. On Thu, Sep 2, 2010 at 9:12 AM, Christopher Faylor wrote: > On Thu, Sep 02, 2010 at 06:08:37AM +0400, Vasya Pupkin wrote: >>Because I prefer to keep things under control. And I don't think it >>will require a huge amount of work to disable working with permissions >>in setup.exe with command line switch. > > Well, go ahead then. What are you waiting for? Send us a patch. > > cgf > > -- > 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 > > filemanip.cc.diff Description: Binary data mkdir.cc.diff Description: Binary data -- 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: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
On Fri, Sep 3, 2010 at 12:49 AM, Andy Koppe wrote: > How did you find the problematic permissions? By looking at the > security tab of the file properties? Did you confirm that users really > were able to modify files they weren't supposed to? Could the > offending privileges have been inherited from the directory Cygwin was > installed in? If only I could remember all the details. I didn't have much time to figure out what happened. Easy solution for me was to disable acl in cygwin, which I did, and was happy until I used setup.exe and found out it destroyed my permissions. -- 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: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
On 9/2/2010 4:49 PM, Andy Koppe wrote: > How did you find the problematic permissions? By looking at the > security tab of the file properties? Remember that the security tab has the very bad habit of re-ordering the ACLs -- but the effect of ACLs is order dependent. Hence, just looking at the permissions of a cygwin-managed directory or file, using the security tab, can introduce a Heisenbug: there was no bug until you observed the permissions. Use getfacl/setfacl to manipulate the permissions/ACLs of cygwin-managed files. -- Chuck -- 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: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
On 2 September 2010 16:05, Vasya Pupkin wrote: > In my case, these additional permissions were allowing everyone to > modify files. Not harmful at all, indeed. I do not remember all the > details, I remember these permissions were everywhere. So I just > replaced everything with proper permissions and disabled acl support > in cygwin. The only problem was setup.exe but now I compiled it with a > modification and this last problem gone. > > I understand that I do not have all the details required for a bug > report. And it wasn't an attempt to report a bug. Intended or not, this is a bug report, and a rather serious one at that. Any further details might be useful. When was it that you saw that problem? Still during the beta phase or after 1.7.1 was released? How did you find the problematic permissions? By looking at the security tab of the file properties? Did you confirm that users really were able to modify files they weren't supposed to? Could the offending privileges have been inherited from the directory Cygwin was installed in? Andy -- 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: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
On Thu, Sep 2, 2010 at 8:25 PM, Jeremy Bopp wrote: > Your answer was simply an assertion that there possibly was and may > still be something wrong with the permissions handling under Cygwin, but > that you also haven't confirmed that recently. The details really would > be helpful and likely necessary if you would like to have your patch > accepted by the maintainers of setup.exe. No, my patch can't be accepted as it removes permissions handling completely. It wasn't me who started the thread and I believe, my patch can be of interest for anyone else who will search for a solution for this specific problem. Anyway, I don't see how an option to switch off permissions handling by setup.exe can harm while there is similar functionality in cygwin itself. My very limited understanding of C is not enough to do this, and I never worked with GUI applications. But I will see if it can be done via command line switch and if I succeed, I will submit a proper patch. -- 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: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
On 9/2/2010 10:05 AM, Vasya Pupkin wrote: > If you read again very carefully, you will see that I modified > permissions AFTER I noticed they were messed up. Ok? I tried to point out that your definition of "messed up" is the opposite of Andy's. To you, the default permissions provided by setup.exe are messed up. To Andy, the permissions you created are messed up. I hope that clarifies things. > In my case, these additional permissions were allowing everyone to > modify files. Not harmful at all, indeed. I do not remember all the > details, I remember these permissions were everywhere. So I just > replaced everything with proper permissions and disabled acl support > in cygwin. The only problem was setup.exe but now I compiled it with a > modification and this last problem gone. Yes, the more I read, the more I come to believe that the disconnect here is in the definition of correct and acceptable permissions. Your definition differs from that of the Cygwin developers. It's good that your permissions changes worked for you, but it's possible that they won't work for everyone. A better description of your original problem as well as how your proposed solution addresses that problem would allow for a more productive discussion. > I understand that I do not have all the details required for a bug > report. And it wasn't an attempt to report a bug. I was asked why I > care about permissions, so I answered. Anyway, the problem is solved > now, I also submitted an easy patch to setup.exe source for everyone > who want to get rid of this problem as well. > > If I ever get into a problem with permissions again, I will try to > make a proper bug report instead of just fixing permissions. Your answer was simply an assertion that there possibly was and may still be something wrong with the permissions handling under Cygwin, but that you also haven't confirmed that recently. The details really would be helpful and likely necessary if you would like to have your patch accepted by the maintainers of setup.exe. The only other option is to independently maintain your patch and rebuild your version of setup.exe any time the upstream version changes. This won't help most users, though, because they will either not know about your patch or not care to build their own setup.exe without having any evidence of an existing problem and assurance that your change doesn't introduce other problems. If you're satisfied with your solution, so be it, but you could pretty quickly gather the necessary details for a bug report by performing a second installation of Cygwin into a new directory and reporting the flawed permissions. That could lead to the acceptance of your patch or something similar to the benefit of everyone. -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: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
If you read again very carefully, you will see that I modified permissions AFTER I noticed they were messed up. Ok? In my case, these additional permissions were allowing everyone to modify files. Not harmful at all, indeed. I do not remember all the details, I remember these permissions were everywhere. So I just replaced everything with proper permissions and disabled acl support in cygwin. The only problem was setup.exe but now I compiled it with a modification and this last problem gone. I understand that I do not have all the details required for a bug report. And it wasn't an attempt to report a bug. I was asked why I care about permissions, so I answered. Anyway, the problem is solved now, I also submitted an easy patch to setup.exe source for everyone who want to get rid of this problem as well. If I ever get into a problem with permissions again, I will try to make a proper bug report instead of just fixing permissions. On Thu, Sep 2, 2010 at 6:28 PM, Jeremy Bopp wrote: > On 9/2/2010 12:49 AM, Vasya Pupkin wrote: >> No, it wasn't a mess of my own making. I did not ever touch >> permissions, and it was a clean install. I don't know where these >> permissions came from, but ls -l displayed something like that for >> most files: > > I read Andy's comment to mean that the mess of your own making is the > result of you changing the permissions, not the existing permissions as > left by setup.exe. You made the mess (or correction as you see it) and > are now fighting with setup.exe to maintain it. > >> drwxr-xr-x+ 1 user group 0 2010-09-02 09:32 tests >> >> This "+" sign after permissions string indicated non-cygwin >> permissions which was impossible to remove using cygwin's chmod. And >> since permissions are not inherited, it was not possible to mass >> remove them using windows either. So, I just removed all permissions >> and forced their inheritance. That solved all problems, until I >> updated installation using setup.exe. > > The "+" indicates that there are further permissions specified as ACLs > for which the getfacl and setfacl commands should be used to view and > manipulate, respectively. You would see the same behavior from ls on a > Linux system which had ACL support and extra ACLs applied to a similar > file or directory. There, too, chmod would not be able to modify those > ACLs. > > What your example does not indicate is that anything unintentional > happened with the application of permissions on that example directory. > Nor does it indicate that the given permissions are in any way harmful > to the maintenance of your system or the use of the files and > directories in question. > > Where was that directory located? Did you create it, or did setup.exe > create it? What problems do those permissions cause? > >> Believe me or not, but I really did not touch any permissions until I >> noticed that strange behaviour. And I am the only administrator. >> Machine is not a part of any domains. So, unless it's a kind of black >> magic, there was (and maybe still is) some issue with permissions in >> cygwin. That is why I don't want to use them. > > I'm sure the Cygwin developers would be more than willing to patch any > defect surrounding the incorrect application of permissions to files > which is the result of Cygwin itself or setup.exe. Unfortunately, you > have not demonstrated any such erroneous behavior yet. It seems more > likely that you have a small misunderstanding about how the permissions > you see work and how they are represented under Cygwin. Have you read > the section of the user guide which discusses permissions under Cygwin? > > Perhaps, you have found a genuine defect. If so, you need to provide > more data so that someone else can reproduce the problem. You could > start by installing another instance of Cygwin into a fresh directory > (this won't affect your primary installation) and then demonstrate the > specific files that have faulty permissions and explain how those > permissions will lead to further problems. > > With luck, someone will be able to explain why things are the way you > see them such that you are comfortable accepting how Cygwin does things. :-) > > -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 > > -- 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: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
On 9/2/2010 12:49 AM, Vasya Pupkin wrote: > No, it wasn't a mess of my own making. I did not ever touch > permissions, and it was a clean install. I don't know where these > permissions came from, but ls -l displayed something like that for > most files: I read Andy's comment to mean that the mess of your own making is the result of you changing the permissions, not the existing permissions as left by setup.exe. You made the mess (or correction as you see it) and are now fighting with setup.exe to maintain it. > drwxr-xr-x+ 1 user group 0 2010-09-02 09:32 tests > > This "+" sign after permissions string indicated non-cygwin > permissions which was impossible to remove using cygwin's chmod. And > since permissions are not inherited, it was not possible to mass > remove them using windows either. So, I just removed all permissions > and forced their inheritance. That solved all problems, until I > updated installation using setup.exe. The "+" indicates that there are further permissions specified as ACLs for which the getfacl and setfacl commands should be used to view and manipulate, respectively. You would see the same behavior from ls on a Linux system which had ACL support and extra ACLs applied to a similar file or directory. There, too, chmod would not be able to modify those ACLs. What your example does not indicate is that anything unintentional happened with the application of permissions on that example directory. Nor does it indicate that the given permissions are in any way harmful to the maintenance of your system or the use of the files and directories in question. Where was that directory located? Did you create it, or did setup.exe create it? What problems do those permissions cause? > Believe me or not, but I really did not touch any permissions until I > noticed that strange behaviour. And I am the only administrator. > Machine is not a part of any domains. So, unless it's a kind of black > magic, there was (and maybe still is) some issue with permissions in > cygwin. That is why I don't want to use them. I'm sure the Cygwin developers would be more than willing to patch any defect surrounding the incorrect application of permissions to files which is the result of Cygwin itself or setup.exe. Unfortunately, you have not demonstrated any such erroneous behavior yet. It seems more likely that you have a small misunderstanding about how the permissions you see work and how they are represented under Cygwin. Have you read the section of the user guide which discusses permissions under Cygwin? Perhaps, you have found a genuine defect. If so, you need to provide more data so that someone else can reproduce the problem. You could start by installing another instance of Cygwin into a fresh directory (this won't affect your primary installation) and then demonstrate the specific files that have faulty permissions and explain how those permissions will lead to further problems. With luck, someone will be able to explain why things are the way you see them such that you are comfortable accepting how Cygwin does things. :-) -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: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
No, it wasn't a mess of my own making. I did not ever touch permissions, and it was a clean install. I don't know where these permissions came from, but ls -l displayed something like that for most files: drwxr-xr-x+ 1 user group 0 2010-09-02 09:32 tests This "+" sign after permissions string indicated non-cygwin permissions which was impossible to remove using cygwin's chmod. And since permissions are not inherited, it was not possible to mass remove them using windows either. So, I just removed all permissions and forced their inheritance. That solved all problems, until I updated installation using setup.exe. Believe me or not, but I really did not touch any permissions until I noticed that strange behaviour. And I am the only administrator. Machine is not a part of any domains. So, unless it's a kind of black magic, there was (and maybe still is) some issue with permissions in cygwin. That is why I don't want to use them. On Thu, Sep 2, 2010 at 9:10 AM, Andy Koppe wrote: > On 2 September 2010 03:08, Vasya Pupkin wrote: >> Because I prefer to keep things under control > > Oh $DEITY. > >> And I don't think it >> will require a huge amount of work to disable working with permissions >> in setup.exe with command line switch. I started to worry about it >> because cygwin failed so much with permissions, having both >> cygwin-specific and inherited ones (copied) at the same time, >> resulting in complete mess. > > That appears to be a mess of your own making. Otherwise, concrete bug > reports please. The OP's complaint here was that permissions aren't > inherited, so I've got no idea what you're on about. > >> A non-privileged user could modify cygwin >> configuration files in /etc and it was not possible to do something >> about it. > > Well, I don't know what you did, but I install Cygwin as administrator > and work as an ordinary user, and no, I can't modify anything in /etc. > And that's no accident of course, because a lot of work has gone into > mapping POSIX permissions to NTFS permissions in a sensible way. > > Andy > > > ps: Please don't top-post. http://www.cygwin.com/acronyms/#TOFU > > -- > 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: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
Will do as soon as I get this thing to at least compile. Actually,
since there is no abstract layer for nt_wfopen(), all calls to this
function have to be modified. Alternatively, the function can be
modified to ignore perms parameter and alternative version of
setup.exe can be compiled then. That is the way I chose, but there is
some problem in another file that I cannot fix myself. You can see my
previous message about that. Regardless, this is the simple patch:
===
--- filemanip.cc2010-03-01 18:18:39.0 +0300
+++ filemanip.cc.new2010-09-02 09:33:05.094182900 +0400
@@ -433,8 +433,10 @@
IO_STATUS_BLOCK io;
UNICODE_STRING uname;
OBJECT_ATTRIBUTES attr;
+ /*
SECURITY_DESCRIPTOR sd;
acl_t acl;
+ */
const char *c;
ULONG access, disp;
int oflags = 0;
@@ -489,11 +491,14 @@
PWCHAR wname = (PWCHAR) wpath;
wname[1] = L'?';
RtlInitUnicodeString (&uname, wname);
+ /*
InitializeObjectAttributes (&attr, &uname, OBJ_CASE_INSENSITIVE, NULL,
disp == FILE_OPEN || perms == 0
? NULL
: nt_sec.GetPosixPerms ("", NULL, NULL,
perms, sd, acl));
+ */
+ InitializeObjectAttributes (&attr, &uname, OBJ_CASE_INSENSITIVE, NULL, NULL);
status = NtCreateFile (&h, access | SYNCHRONIZE, &attr, &io, NULL,
FILE_ATTRIBUTE_NORMAL, FILE_SHARE_VALID_FLAGS, disp,
FILE_OPEN_FOR_BACKUP_INTENT
===
Instead of commenting code, defines can be used to allow choosing
required behaviour at compile time.
On Thu, Sep 2, 2010 at 9:12 AM, Christopher Faylor
wrote:
> On Thu, Sep 02, 2010 at 06:08:37AM +0400, Vasya Pupkin wrote:
>>Because I prefer to keep things under control. And I don't think it
>>will require a huge amount of work to disable working with permissions
>>in setup.exe with command line switch.
>
> Well, go ahead then. What are you waiting for? Send us a patch.
>
> cgf
>
> --
> 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: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
On Thu, Sep 02, 2010 at 06:08:37AM +0400, Vasya Pupkin wrote: >Because I prefer to keep things under control. And I don't think it >will require a huge amount of work to disable working with permissions >in setup.exe with command line switch. Well, go ahead then. What are you waiting for? Send us a patch. cgf -- 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: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
On 2 September 2010 03:08, Vasya Pupkin wrote: > Because I prefer to keep things under control Oh $DEITY. > And I don't think it > will require a huge amount of work to disable working with permissions > in setup.exe with command line switch. I started to worry about it > because cygwin failed so much with permissions, having both > cygwin-specific and inherited ones (copied) at the same time, > resulting in complete mess. That appears to be a mess of your own making. Otherwise, concrete bug reports please. The OP's complaint here was that permissions aren't inherited, so I've got no idea what you're on about. > A non-privileged user could modify cygwin > configuration files in /etc and it was not possible to do something > about it. Well, I don't know what you did, but I install Cygwin as administrator and work as an ordinary user, and no, I can't modify anything in /etc. And that's no accident of course, because a lot of work has gone into mapping POSIX permissions to NTFS permissions in a sensible way. Andy ps: Please don't top-post. http://www.cygwin.com/acronyms/#TOFU -- 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: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
Because I prefer to keep things under control. And I don't think it will require a huge amount of work to disable working with permissions in setup.exe with command line switch. I started to worry about it because cygwin failed so much with permissions, having both cygwin-specific and inherited ones (copied) at the same time, resulting in complete mess. A non-privileged user could modify cygwin configuration files in /etc and it was not possible to do something about it. That is when I decided to control permissions myself, but cygwin setup overwrites permissions on every install, including files in /etc, messing up everything. On Thu, Sep 2, 2010 at 12:18 AM, Andy Koppe wrote: > On 1 September 2010 15:18, Vasya Pupkin wrote: >>> Do creating any entries in /etc/passwd or /etc/group or /etc/fstab >>> files can overcome this... >> >> Nothing can overcome thins until setup.exe is modified to support >> noacl option in /etc/fstab or get a similar comman line parameter or >> even a checkbox. > > Reading /etc/fstab wouldn't work for the initial install. All these > possibilities require a substantial amount of (voluntary) work, yet so > far the only reason you've given for it was that you "don't like how > cygwin works with NTFS permissions and therefore it is disabled > through /etc/fstab". It shouldn't surprise you that that doesn't put > it high on anyone's list of priorities. > > So why do you care about permissions on files that come with setup.exe > packages? Setup.exe won't touch /home or anything outside the Cygwin > install. > > Andy > > -- > 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: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
On 1 September 2010 15:18, Vasya Pupkin wrote: >> Do creating any entries in /etc/passwd or /etc/group or /etc/fstab >> files can overcome this... > > Nothing can overcome thins until setup.exe is modified to support > noacl option in /etc/fstab or get a similar comman line parameter or > even a checkbox. Reading /etc/fstab wouldn't work for the initial install. All these possibilities require a substantial amount of (voluntary) work, yet so far the only reason you've given for it was that you "don't like how cygwin works with NTFS permissions and therefore it is disabled through /etc/fstab". It shouldn't surprise you that that doesn't put it high on anyone's list of priorities. So why do you care about permissions on files that come with setup.exe packages? Setup.exe won't touch /home or anything outside the Cygwin install. Andy -- 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: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
Nothing can overcome thins until setup.exe is modified to support noacl option in /etc/fstab or get a similar comman line parameter or even a checkbox. On Wed, Sep 1, 2010 at 6:00 PM, Harie Ram wrote: > Do creating any entries in /etc/passwd or /etc/group or /etc/fstab > files can overcome this... > > Thanks > > On Wed, Sep 1, 2010 at 7:21 PM, Vasya Pupkin wrote: >> Cygwin uses NTFS ACLs to imitate POSIX style permissions. It can also >> be configured to not touch ACL's at all, but setup program ignores >> that and messes up permissions every time something is >> installed/updated. >> >> On Wed, Sep 1, 2010 at 4:49 PM, Rolf Campbell >> wrote: >>> On 2010-09-01 04:00, Harie Ram wrote: The issue that I am currently facing is : the modify permissions given to the INSTALLDIR "C:\Cygwin" using the msi lock permission table is being inherited through all the subfolders and files. Any new manually created folders and files anywhere within C:\Cygwin via Windows explorer or via the Cygwin Bash Shell are inheriting permissions. But any new installations done by the user by choosing a package from the Cygwin list are not inheriting the permissions. The installed user who installs the package has full permissions to delete/modify the folder and its contents . But the local admin/administrator/system does not have permissions. It gives an access denied error. These 3 user groups administrators/system/users are not even being listed in the security properties of those installed folders. >>> >>> AFAIK, Cygwin uses POSIX style file permissions, which do not support any >>> type of inherited file permissions. >>> >>> >>> -- >>> 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 >> >> > > -- > 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: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
Do creating any entries in /etc/passwd or /etc/group or /etc/fstab files can overcome this... Thanks On Wed, Sep 1, 2010 at 7:21 PM, Vasya Pupkin wrote: > Cygwin uses NTFS ACLs to imitate POSIX style permissions. It can also > be configured to not touch ACL's at all, but setup program ignores > that and messes up permissions every time something is > installed/updated. > > On Wed, Sep 1, 2010 at 4:49 PM, Rolf Campbell > wrote: >> On 2010-09-01 04:00, Harie Ram wrote: >>> >>> The issue that I am currently facing is : the modify permissions given >>> to the INSTALLDIR "C:\Cygwin" using the msi lock permission table is >>> being inherited through all the subfolders and files. Any new manually >>> created folders and files anywhere within C:\Cygwin via Windows >>> explorer or via the Cygwin Bash Shell are inheriting permissions. But >>> any new installations done by the user by choosing a package from the >>> Cygwin list are not inheriting the permissions. The installed user who >>> installs the package has full permissions to delete/modify the folder >>> and its contents . But the local admin/administrator/system does not >>> have permissions. It gives an access denied error. These 3 user groups >>> administrators/system/users are not even being listed in the security >>> properties of those installed folders. >> >> AFAIK, Cygwin uses POSIX style file permissions, which do not support any >> type of inherited file permissions. >> >> >> -- >> 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 > > -- 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: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
Cygwin uses NTFS ACLs to imitate POSIX style permissions. It can also be configured to not touch ACL's at all, but setup program ignores that and messes up permissions every time something is installed/updated. On Wed, Sep 1, 2010 at 4:49 PM, Rolf Campbell wrote: > On 2010-09-01 04:00, Harie Ram wrote: >> >> The issue that I am currently facing is : the modify permissions given >> to the INSTALLDIR "C:\Cygwin" using the msi lock permission table is >> being inherited through all the subfolders and files. Any new manually >> created folders and files anywhere within C:\Cygwin via Windows >> explorer or via the Cygwin Bash Shell are inheriting permissions. But >> any new installations done by the user by choosing a package from the >> Cygwin list are not inheriting the permissions. The installed user who >> installs the package has full permissions to delete/modify the folder >> and its contents . But the local admin/administrator/system does not >> have permissions. It gives an access denied error. These 3 user groups >> administrators/system/users are not even being listed in the security >> properties of those installed folders. > > AFAIK, Cygwin uses POSIX style file permissions, which do not support any > type of inherited file permissions. > > > -- > 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: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
On 2010-09-01 04:00, Harie Ram wrote: The issue that I am currently facing is : the modify permissions given to the INSTALLDIR "C:\Cygwin" using the msi lock permission table is being inherited through all the subfolders and files. Any new manually created folders and files anywhere within C:\Cygwin via Windows explorer or via the Cygwin Bash Shell are inheriting permissions. But any new installations done by the user by choosing a package from the Cygwin list are not inheriting the permissions. The installed user who installs the package has full permissions to delete/modify the folder and its contents . But the local admin/administrator/system does not have permissions. It gives an access denied error. These 3 user groups administrators/system/users are not even being listed in the security properties of those installed folders. AFAIK, Cygwin uses POSIX style file permissions, which do not support any type of inherited file permissions. -- 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
