Re: [ANNOUNCEMENT] Updated: setup (2.898)
On Wed, Jan 1, 2020 at 11:22 AM Jon Turney wrote: > > > I've built setup with a patch which attempts to address this: > > https://cygwin.com/setup/setup-2.899.x86_64.exe > https://cygwin.com/setup/setup-2.899.x86.exe > > Perhaps you could try that and see if it improves things for you? Yes, it appears to be working as expected with this new build. Thanks! -- 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: [ANNOUNCEMENT] Updated: setup (2.898)
On Sat, Dec 28, 2019 at 8:40 AM Jon Turney wrote: > > > A new version of Setup (2.898) has been uploaded to: > >https://cygwin.com/setup-x86_64.exe (64 bit version) >https://cygwin.com/setup-x86.exe (32 bit version) Something definitely busted in this version for me. I've been using the same command line to download an offline, partial mirror for more than 5 years: setup-x86_64.exe --disable-buggy-antivirus --download --no-desktop --root "%CD%\Temp" --quiet-mode --categories All --remove-categories Debug --local-package-dir "%CD%" --site "%MIRROR%" On a clean directory structure, this now stops executing without downloading anything: Starting cygwin install, version 2.898 User has backup/restore rights io_stream_cygfile: fopen(/etc/setup/setup.rc) failed 2 No such file or directory Current Directory: V:\Installers\Cygwin\x64 Could not open service McShield for query, start and stop. McAfee may not be installed, or we don't have access. Selected local directory: V:\Installers\Cygwin\x64 net: Preconfig site: http://mirrors.koehn.com/cygwin/cygwin-ftp/ HTTP status 404 fetching http://mirrors.koehn.com/cygwin/cygwin-ftp/x86_64/setup.zst.sig HTTP status 404 fetching http://mirrors.koehn.com/cygwin/cygwin-ftp/x86_64/setup.zst io_stream_cygfile: fopen(/etc/setup/timestamp) failed 2 No such file or directory io_stream_cygfile: fopen(/etc/setup/installed.db) failed 2 No such file or directory solving: 11308 tasks, update: no, use test packages: no -- 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: Repairing permissions after windows reinstall
> In fact I see _two_ raw SIDs when I look at the security tab for any > directory in the old cygwin tree: one has Full control, and the other > just Read & execute. > If everyone else's posts don't get you where you want, I have a recently-written program that can do a search/replace on a SID (or named account) on an entire directory directory (addresses DACL/SACL group SID, owner SID). Message me directly if you're interested. -- 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: Question about tar v1.28
> Could be an accidental regression in my cygwin-specific patches betweenthe > two versions. But I don't normally use or test on text-mounts, so > I'll need confirmation that you are indeed experiencing the problem only > For what it's worth, I recently had the similar issues with Cygwin tar on text-mounted volumes in the last year. We had users moving between Cygwin tar and Redhat tar and there were issues extracting the tar files. I instructed them to create a binary mount for tar-related purposes and that addressed the issue. We need to use text-mounts, in general, for other reasons. It would be great if tar could be adjusted to operate properly in these scenarios. -- 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: Restrict active directory logins
On Mon, Aug 31, 2015 at 11:39 PM, E. Winston wrote: > Hi all, > > I am running cygwin 2.2.1(0.289/5/3) and OpenSSH_7.1p1, OpenSSL 1.0.2d 9 Jul > 2015 on a domain joined Windows 2012 R2 server. I am not using /etc/passwd or > /etc/group and I would prefer not to use theses files as I anticipate a large > number of accounts needing to be configured. As part of our group policy, NT > AUTHORITY\Authenticated Users and NT AUTHORITY\Interactive are both part of > the local Users group. The group policy also places NT > AUTHORITY\Authenticated Users into "Log on Locally" security policy. My > primary purpose is to use this as an SFTP server. I have been able to deny > SSH logins and limit access to on SFTP. > > What I would like to know is with this setup, is if there is a way to prevent > any user in our domain from logging into the server? > > Currently I have directory permissions set so they cannot see anything, but > I'd rather not allow them to login at all. > > I have a local group created with only the domain accounts I want to be able > to explicitly login but thus far I have not been able to determine how to > limit logins to just the members of this group. > > Thanks in advance, > > -Ed > -- > 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 > Ed, I have a similar arrangement. Short of reprogramming Cygwin to *not* do an interactive logon (i.e. do a network logon instead), I think you're out of luck. A network logon would work for what an SFTP server needs to do, but probably isn't right for other purposes such as a full SSH terminal session -- and unfortunately both authentication process goes through the same function in Cygwin. I thought about proposing some configurable setting in Cygwin on the mailing list, but the need is really too nuanced to merit implementation (in my opinion). If the users don't have access to the console, just make sure that you're not also allowing "Allow log on through Remote Desktop Services" -- that should prevent a user from being logged into via Remote Desktop. That said, the problem may actually be worse than you think. If you have roaming profiles enabled, they may be getting synced every time a user logs in via SFTP. If this isn't desired, you'll want to enable user profile cleanup and disable roaming profiles to that system, in general. It'll slow down the login in addition to bloat the profile directory. -- 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: [ANNOUNCEMENT] Early Deprecation Notice: Windows XP and Server 2003 support
On Wed, Aug 26, 2015 at 8:23 AM, Andrey Repin wrote: > Greetings, Corinna Vinschen! > >> On Aug 26 12:56, Helmut Karlowski wrote: >>> > > Guess that's better than to stick with the kludges, migration to 10 is >>> > > on the way. >>> > From what I've seen and heard W10, while mostly stable, still coerces >>> > users >>> > towards the software as (an expensive) service model and follows the >>> > dictum >>> > that Microsoft knows more about what you want than you do (default saves >>> > to >>> > microsoft cloud storage, grabs your pictures for background slide show >>> > without asking, etc.). >>> >>> I hope I can customize it to behave like XP (only the goodies of >>> course). > >> http://classicshell.net > > That doesn't solve the hotkeys bound at driver levels, unfortunately. > Half of my keyboard dead now thanks to the move to Win7. > > Anyway, on the topic: All I could ask is to give us a notice when the final > build for XP is available, so that we could prepare own mirrors. If you're passionate about it and you have any programming experience, keyboard filter drivers are quite easy to write. Only annoying thing is you need a signing certificate that is authorized for kernel code signing -- which is only available to companies and some slightly more expensive issuing authorities for individuals. -- 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: Unable to run excel via cron
On Tue, Jun 16, 2015 at 9:27 AM, Kertz, Denis (D)** CTR **
wrote:
> We need to run some Excel programs via cron and are using vbscript to do
> this. We have this running on a WinXP machine but are having trouble running
> on a Win7 machine, but we don't think it is a Win7 problem.
>
> Here's the script to run a simple test excel program:
>
> Dim xlApp
> Dim xlWb
> Set xlApp = CreateObject("Excel.application")
> xlApp.Visible = True
> Set xlWb = xlApp.workbooks.Open("c:\Shared\Prospect\Bin\TestExcel.xls")
> xlApp.Quit
> Set xlWb = Nothing
> Set xlApp = Nothing
>
What bitness of Excel and Cygwin are you running?
CreateObject("Excel.application") will attempt to create a 32-bit
instance of Excel when launched through the 32-bit version of
wscript.exe or a 64-bit instance of Excel when launched through the
64-bit version of Excel. Which bitness of WScript.exe ends up being
run will depend on the bitness of the parent program (which may be
different in a command prompt vice Cygwin). Try changing it to run
Wscript.exe in SysWow64 instead of System32 (which is subject to
automatic redirection) and see if changes the behavior. If you're not
running a 64-bit OS, then just ignore everything I said.
--
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: startxwin - xinit unable to connect to X server
On Wed, May 13, 2015 at 2:40 PM, Kunz, Christopher L wrote: > After updating to the latest Cygwin distribution, I can no longer connect to > X server. When I run startxwin (on a fresh Cygwin install), I get the > following errors: > > xinit: giving up > xinit: unable to connect to X server: Connection refused > xinit: server error > > The XWin.#.log looks okay, I think (see attached). I've set DISPLAY to :0.0. > > Thanks. When's the last time you had updated the xinit package? Try launching as startxwin as startxwin -- -listen tcp -- 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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.8
Did the fix for my Unknown user/group caching make it over from 2.0.0-0.7 (previous change note below)? - Fix a bug in SID handling which may result in broken SID info in passwd/group entries of unknown accounts. -- 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: Running tasklist /m in cygwin hangs
On Wed, Apr 15, 2015 at 1:52 PM, Saurabh T wrote: > Hi, > Running > "tasklist /m file.dll" hangs in Cygwin even though it works perfectly > fine in the cmd window. Is there any reason for this? I am using a > somewhat older cygwin (1.7.25) on a Windows 7 box, and do not want to > upgrade unless newer cygwin doesnt show the problem. Thank you. > -- > 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 > It doesn't hang for me, but it is significantly slower. I'm running the latest development release. Tasklist appears to be WMI heavy. I ran Process Monitor and it appears that when running tasklist /m under bash, WMI is significantly more active. WMI actually opens tzres.dll (Time Zone Resources) about 150,000 times vice a mere 800 times when executing through a standard command prompt. Moreover, WMI really doesn't appear to be doing much of anything with tzres.dll... just open/close/open/close/open/close. Very curious indeed. -- 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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-5
On Fri, Apr 17, 2015 at 6:07 AM, Corinna Vinschen wrote: > On Apr 17 10:16, Corinna Vinschen wrote: >> On Apr 16 12:53, Bryan Berns wrote: >> > On Thu, Apr 16, 2015 at 10:17 AM, Jim Reisert AD1C >> > wrote: >> > > I am unable to start Cywin/X X-server 1.17.1 with this version. >> > > Previous releases of 2.0.0.x were OK. I had to revert to 1.7.35-1 for >> > > the time being. >> > > >> > > Other than updating to 2.0.0.5, I also installed the April 2015 "Patch >> > > Tuesday" updates from Microsoft. I don't know if the two are related. >> > > Windows 7 Home Premium, 64-bit >> > > >> > > Exception: STATUS_ACCESS_VIOLATION at eip=77C50F8A >> > > eax= ebx=612D67B0 ecx=1000 edx=612D2648 esi= >> > > edi=0028C790 >> > > ebp=0028C608 esp=0028C604 program=C:\Cygwin\bin\XWin.exe, pid 1660, >> > > thread main >> > > cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B >> > > Stack trace: >> > > Frame Function Args >> > > 0028C608 77C50F8A (, 612D2648, , 612D67B0) >> > > 0028C738 610CDA1F (43FF, , , 80012428) >> > > 0028C7B8 61047198 (, 72483F24, 75604227, 0254) >> > > 0028C7F8 610F629D (0001, , , 75623912) >> > > >> > > -- >> > > Jim Reisert AD1C, , http://www.ad1c.us >> > >> > I've actually had problem building Cygwin (1.7.35 or 2.x source) on >> > Cygwin 2.x using Windows. The make errors out with a "permissions >> > denied" when setting permissions (chmod +x) on config.status in >> > /etc. I was able to produce it on three different, freshly >> > built copies of Windows (no BLODA at all). Only had Cygwin plus the >> > build essentials (gcc, ming, xmlto, diffutils, textinfo, cocom) >> > installed. Only tried with 32-bit. >> > >> > The super wacky thing is that if I rearrange the unrelated contents of >> > the make file that fuels the whole process, the problem goes away. If >> > I "downgrade" the core back to 1.7.35, the problem goes away. It >> > almost seems like there might an uninitialized memory issue in the >> > code path executed in chmod(). I apologize for the lack of debugging >> > on my part, but I just wanted to throw this out there in case a) it >> > could be related to this issue or b) anyone else has seen this. >> >> This is more in line with what Ismail reported in >> https://cygwin.com/ml/cygwin/2015-04/msg00365.html >> >> And I finally managed to reproduce it. It works on the command line and >> only fails during `make' for me. Investigating now... > > I think I found the culprit. I'll uploade a -0.7 test release in > the next hour or so. > > > Thanks for testing, > Corinna > > -- > Corinna Vinschen Please, send mails regarding Cygwin to > Cygwin Maintainer cygwin AT cygwin DOT com > Red Hat On my way to work now and probably will be offline most of the day, but just wanted to let you know that I did a quick rip of the DLL file from cygwin-2.0.0-0.7.tar.xz on the sourceware.org mirror and make / chmod seems happier now. Nice! :-) -- 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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-5
On Thu, Apr 16, 2015 at 10:17 AM, Jim Reisert AD1C wrote: > I am unable to start Cywin/X X-server 1.17.1 with this version. > Previous releases of 2.0.0.x were OK. I had to revert to 1.7.35-1 for > the time being. > > Other than updating to 2.0.0.5, I also installed the April 2015 "Patch > Tuesday" updates from Microsoft. I don't know if the two are related. > Windows 7 Home Premium, 64-bit > > Exception: STATUS_ACCESS_VIOLATION at eip=77C50F8A > eax= ebx=612D67B0 ecx=1000 edx=612D2648 esi= edi=0028C790 > ebp=0028C608 esp=0028C604 program=C:\Cygwin\bin\XWin.exe, pid 1660, thread > main > cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B > Stack trace: > Frame Function Args > 0028C608 77C50F8A (, 612D2648, , 612D67B0) > 0028C738 610CDA1F (43FF, , , 80012428) > 0028C7B8 61047198 (, 72483F24, 75604227, 0254) > 0028C7F8 610F629D (0001, , , 75623912) > > -- > Jim Reisert AD1C, , http://www.ad1c.us I've actually had problem building Cygwin (1.7.35 or 2.x source) on Cygwin 2.x using Windows. The make errors out with a "permissions denied" when setting permissions (chmod +x) on config.status in /etc. I was able to produce it on three different, freshly built copies of Windows (no BLODA at all). Only had Cygwin plus the build essentials (gcc, ming, xmlto, diffutils, textinfo, cocom) installed. Only tried with 32-bit. The super wacky thing is that if I rearrange the unrelated contents of the make file that fuels the whole process, the problem goes away. If I "downgrade" the core back to 1.7.35, the problem goes away. It almost seems like there might an uninitialized memory issue in the code path executed in chmod(). I apologize for the lack of debugging on my part, but I just wanted to throw this out there in case a) it could be related to this issue or b) anyone else has seen this. That said, I'm making progress in debugging my "Unknown Group" issue described in another chain; hope to report out on that this weekend when I have a little more time to play. -- 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: Making Cygwin More Tolerant of Orphaned SIDs?
On Wed, Apr 15, 2015 at 3:29 AM, Corinna Vinschen wrote: > > Not off the top of my head. The mechanism doesn't check for the > content so it should cache the above line the same way as any other. > I'm puzzled about this behaviour myself. > > That requires some debugging but I have other stuff on my plate atm > so it will take a while(*). For the time being, use noacl mounts. > > > Corinna > > (*) Of course, I'd appreciate any other person debugging what happens > in Cygwin and Cygserver a lot. We can discuss questions on serious > debugging efforts on the cygwin-developers mailing list. I know C/C++ and IPC quite well so I'll try to take a look tomorrow night. Of course, I'm still a novice when it comes to the Cygwin internals so it may take a bit. Thanks Corinna! -- 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: Making Cygwin More Tolerant of Orphaned SIDs?
On Tue, Apr 14, 2015 at 2:23 PM, Corinna Vinschen wrote: > On Apr 14 12:44, Bryan Berns wrote: >> On Tue, Apr 14, 2015 at 10:53 AM, Corinna Vinschen >> wrote: >> > On Apr 14 07:24, Bryan Berns wrote: >> >> For example, I create a whole bunch of files (like 5000), I use >> >> icacls to append a new ACE. Then I do a 'time ls -l >> >> /cygdrive/c/somedir/*'. Takes four seconds. In the same Cygwin >> >> session, I remove the local group (net localgroup testgroup /delete). >> >> I do the same 'time ls -l /cygdrive/c/somedir/*'. Takes 20 seconds. >> >> Subsequent runs in the also take 20 seconds. Since I'm able to >> >> continue to see the slowdown in the same session, cygserver wouldn't >> >> help right? >> >> >> >> Is the above expected? >> > >> > Yes. Without cygserver, caching only works from parent to child process. >> > One run of ls can't cache data for a parallel run of ls in trhe same >> > session. As, btw., explained in the documentation: >> > >> > https://cygwin.com/cygwin-ug-net/ntsec.html >> >> Alright, I'll give it a shot when I get back to my lab. I suspect it >> shouldn't take an additional 16 seconds to attempt to lookup account >> information (and fail) on my two node test network so I'm curious how >> much this will cut the time by. >> If I setup cygserver with all the --no options set (reference: >> https://cygwin.com/cygwin-ug-net/using-cygserver.html) since I don't >> want any accidental cross-user information sharing, will that >> effectively only provide the SID caching functionality or is there >> other functionality to be wary of? > > You don't have to disable anything. Just don't set the debug option > to avoid logging passwd entries. > Finally tested with cygserver (temporarily with debug on so I can see what's going on). I can definitely see the one entry returned when I run 'ls -l' over my whole collection of files while my test group (LocalGroupTest) is still present. Sample log as follows: /home/corinna/src/cygwin/cygwin-2.0.0/prerelease/cygwin-2.0.0-0.4.i686/src/newlib-cygwin/winsup/cygserver/pwdgrp.cc, line 167: Request account information returns error 0 If I delete the group while cygserver is running, the results continue to be speedy. However, as soon as I delete the group and restart cygserver, things go south. Performance is even worse than without cygserver and there are entries for EVERY file that 'ls' is hitting even though they all have the same group in the ACL so it appears the 'Unknown' users/groups are not being cached. Sample log as follows (one of thousands of lines): Request account information returns error 0 Thoughts? -- 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: Making Cygwin More Tolerant of Orphaned SIDs?
On Tue, Apr 14, 2015 at 10:53 AM, Corinna Vinschen wrote: > On Apr 14 07:24, Bryan Berns wrote: >> On Tue, Apr 14, 2015 at 4:00 AM, Corinna Vinschen >> > >> > The problem is that Cygwin, or any other tool trying to resolve SIDs >> > doesn't know a SID won't resolve before it tried. And then it's an >> > OS function which takes its time. It's like checking for network >> > machines providing shares. Sometimes this test takes ages, but in >> > this case, fortunately, you see that it takes ages in Explorer as >> > well. >> > >> > As for ACLs, you can alleviate the problem somewhat by running cygserver >> > on the machine, which allows to cache SIDs for all processes. So only >> > the first process trying the SID will take time, followup processes will >> > get the cached results from cygserver. >> > >> > Other than that, except for ignoring ACLs entirely (noacl) I have >> > no idea how to solve this problem differently. >> >> Yes, I understand there's nothing Cygwin can do beforehand -- that >> means sense. I guess what I'm saying is that Cygwin doesn't appear to >> be caching SIDs in certain scenarios. >> >> For example, I create a whole bunch of files (like 5000), I use >> icacls to append a new ACE. Then I do a 'time ls -l >> /cygdrive/c/somedir/*'. Takes four seconds. In the same Cygwin >> session, I remove the local group (net localgroup testgroup /delete). >> I do the same 'time ls -l /cygdrive/c/somedir/*'. Takes 20 seconds. >> Subsequent runs in the also take 20 seconds. Since I'm able to >> continue to see the slowdown in the same session, cygserver wouldn't >> help right? >> >> Is the above expected? > > Yes. Without cygserver, caching only works from parent to child process. > One run of ls can't cache data for a parallel run of ls in trhe same > session. As, btw., explained in the documentation: > > https://cygwin.com/cygwin-ug-net/ntsec.html Alright, I'll give it a shot when I get back to my lab. I suspect it shouldn't take an additional 16 seconds to attempt to lookup account information (and fail) on my two node test network so I'm curious how much this will cut the time by. If I setup cygserver with all the --no options set (reference: https://cygwin.com/cygwin-ug-net/using-cygserver.html) since I don't want any accidental cross-user information sharing, will that effectively only provide the SID caching functionality or is there other functionality to be wary of? Thanks for everything! Bryan -- 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: Making Cygwin More Tolerant of Orphaned SIDs?
On Tue, Apr 14, 2015 at 4:00 AM, Corinna Vinschen > > The problem is that Cygwin, or any other tool trying to resolve SIDs > doesn't know a SID won't resolve before it tried. And then it's an > OS function which takes its time. It's like checking for network > machines providing shares. Sometimes this test takes ages, but in > this case, fortunately, you see that it takes ages in Explorer as > well. > > As for ACLs, you can alleviate the problem somewhat by running cygserver > on the machine, which allows to cache SIDs for all processes. So only > the first process trying the SID will take time, followup processes will > get the cached results from cygserver. > > Other than that, except for ignoring ACLs entirely (noacl) I have > no idea how to solve this problem differently. Yes, I understand there's nothing Cygwin can do beforehand -- that means sense. I guess what I'm saying is that Cygwin doesn't appear to be caching SIDs in certain scenarios. For example, I create a whole bunch of files (like 5000), I use icacls to append a new ACE. Then I do a 'time ls -l /cygdrive/c/somedir/*'. Takes four seconds. In the same Cygwin session, I remove the local group (net localgroup testgroup /delete). I do the same 'time ls -l /cygdrive/c/somedir/*'. Takes 20 seconds. Subsequent runs in the also take 20 seconds. Since I'm able to continue to see the slowdown in the same session, cygserver wouldn't help right? Is the above expected? If not and it's something you're willing to take a look at, I can certainly come up with a little script to demonstrate the issue. -- 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: Making Cygwin More Tolerant of Orphaned SIDs?
On Tue, Apr 14, 2015 at 4:00 AM, Corinna Vinschen wrote: > > Orphaned SIDs shouldn't happen. Disabling accounts, ok, but removing > them? I don't know. So the question is, if there's no account with > these SIDs anymore, why aren't these SIDs removed from the ACLs? > It's not only Cygwin. These SIDs also unnecessarily slow down each > single access check of the OS. > In principal, I agree 100%. Unfortunately, in some large enterprise environments removal of orphaned SIDs rarely happens on a regular basis. The best way to manage this is typically to only delegate access via groups and have those groups aligned to the file system structure in some way (which tends to change less in practice than company organizational structure). Still, when you've got dozens of people starting/leaving every week, per account permission are occasionally established enumerating more a petabyte of data across several sites to cleanup ACEs is certainly possible but not on the top list of things to do (and mass alteration of ACLs carries some liability to it). Don't get me wrong, my anal retentive nature makes me cringe when I see an orphaned SID; it's just the reality of the situation. That said, the origin of my question was actually not due to unresolvable SIDs to due to removed accounts --- it was just the easiest one to describe. The reason I noticed this is because we have some NTFS assignments via local groups on a remote computers (and those local groups then have nested Active Directory groups). So the ACE has REMOTECOMPUTER\Group vice DOMAIN\Group. When Cygwin attempts to retrieve information on these accounts, it seems to fail and causes delays. So with the newer versions of Cygwin, doing an 'ls -l' went from 2 seconds to more than 30 seconds on some particular file directories. As Achim alluded, 'noacl' may be be the way to go for us, but I was just asking the question in the even there was a configurable setting or a feature enhancement that could be integrated to deal with these scenarios. Of course, 'noacl' seems to mark group / other masks as readable so apps that do permissions checks on these files will return inaccurate results :-(. -- 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
Making Cygwin More Tolerant of Orphaned SIDs?
Based on some rudimentary performance tests, it would appear that Cygwin may repeatedly try to lookup information on a SID form an ACE if cannot find a corresponding account which will undoubtedly occur for orphaned SIDs. If the volume being read is remote, this can result in some massive slowdowns if there are many files in the directory. Is there any way to augment this behavior? -- 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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-3
> On Apr 12 17:19, Bryan Berns wrote: >> On Sun, Apr 12, 2015 at 3:17 PM, Corinna Vinschen >> wrote: >> >> V:\>icacls touch-from-3 >> touch-from-3 DOMAIN\Administrator:(R,W,D,WDAC,WO) >> DOMAIN\Domain Users:(R) >> Everyone:(R) >> BUILTIN\Administrators:(F) >> NT AUTHORITY\SYSTEM:(F) >> NT AUTHORITY\Authenticated Users:(M) >> BUILTIN\Users:(RX) > > I don't believe this is an ACL created by Cygwin 2.0.0 at all. > It's missing the NULL deny ACE. Now that I'm testing again, I think you're right; I had an older installation on my backup drive try that I think somehow tainted one of my sessions. I'll include version information in my output in the future. Sorry! -- 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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-3
On Sun, Apr 12, 2015 at 3:17 PM, Corinna Vinschen wrote: > Hi Cygwin friends and users, > > > New 2.0.0-0.3 test release. It's supposed to fix the pty chmod problem > reported in https://cygwin.com/ml/cygwin/2015-04/msg00240.html > Just a note: In 2.0.0-0.2, creating a file using touch on the root of one of my drives resulted in the with the Windows GUI Security tabs complaining about ACE order on the resultant file. In 2.0.0-0.3, Windows does not complain and the ACL looks quite a bit different (shown below). Not sure if this is a problem or not --- just wanted to report the difference in case your fix had an unintended side affect. Given my heart skips a beat when I see DENY ACEs, I like the new behavior behavior better. V:\>icacls v: v: BUILTIN\Administrators:(OI)(CI)(F) NT AUTHORITY\SYSTEM:(OI)(CI)(F) NT AUTHORITY\Authenticated Users:(OI)(CI)(M) BUILTIN\Users:(OI)(CI)(RX) Output from file created from 2.0.0-0.3: V:\>icacls touch-from-3 touch-from-3 DOMAIN\Administrator:(R,W,D,WDAC,WO) DOMAIN\Domain Users:(R) Everyone:(R) BUILTIN\Administrators:(F) NT AUTHORITY\SYSTEM:(F) NT AUTHORITY\Authenticated Users:(M) BUILTIN\Users:(RX) Successfully processed 1 files; Failed processing 0 files Output from file created from 2.0.0-0.2: V:\>icacls touch-from-2 touch-from-2 NULL SID:(DENY)(Rc,S,WEA,X,DC) DOMAIN\Administrator:(R,W,D,WDAC,WO) DOMAIN\Domain Users:(DENY)(S,X) NT AUTHORITY\Authenticated Users:(DENY)(S,X) BUILTIN\Users:(DENY)(S,X) DOMAIN\Domain Users:(RX) NT AUTHORITY\Authenticated Users:(RX,W) NT AUTHORITY\SYSTEM:(RX,W) BUILTIN\Administrators:(RX,W) BUILTIN\Users:(RX) Everyone:(R) Successfully processed 1 files; Failed processing 0 files -- 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: [TESTERS needed] New POSIX permission handling
>> > That means, even if SYSTEM or Administrators have full access to the >> > file, the POSIX permssion bits will not reflect that fact. And while >> > other users get access denied based on the mask value, SYSTEM and >> > Administrators will never get access denied based on the mask. >> >> If you want to put this to better use in larger settings it would seem >> preferrable if it was possible to define a list of users to treat this >> way in fstab. > > Nope, sorry, no configuration for this. Either it's handled without > any exception, or for SYSTEM only, or for SYSTEM+Admins. But either > way, we're doing it the same way on every system. Damn. I was about to reply with Achim's exact same thought --- like a file in /etc with a list of SIDs. I can empathize with Corinna's veto though -- having a hundred tweak-able settings in Cygwin is unmaintainable for the general populous. I may apply a local patch to extend this ability myself because Cygwin has become rather unusable for users with home's on our network drives (given all the programs that attempt to do sanity checks on group perms). That said, I appreciate what has been integrated --- it will help in several scenarios. I will test the release this weekend. Thanks for all the hard work! -- 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: Robocopy
On Thu, Apr 2, 2015 at 1:47 PM, Houder wrote: > 2015/04/02 19:13:56 ERROR 5 (0x0005) Copying File > E:\Cygwin\home\jvdwater\.bash_history > Access is denied. > Waiting 30 seconds... Retrying... > New File 689.bash_history ROBOCOPY is very reliable and it's actually what I use to have folks "install" Cygwin on our enterprise systems (i.e. I setup a master replica of the install and they ROBOCOPY it down to their machines). It works without fail unless they have a files in use. If you throw in /R:0, do you see any other files with access denied? Might be a good datapoint to confirm it's everything and not something specify about bash_history. -- 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: File Permissions - Yet Another Question / Clarification
Replying to myself on this topic in case anyone else is interested. > 2) how can I get SSH to believe the two "admin" groups on my > files are acceptable. I'm not optimistic I'm going to get SSH to > change it's behavior so I may need to recompile it to avoid the > check which is obviously not desirable from a maintainability > standpoint. The applicable check at work here is check_ntsec() and the several lines after within authfile.c in the openssh package. I confirmed there is no elegant way to avoid or externally augment these checks as it's currently programmed without patching and recompiling (or using something like Microsoft Detours to fake out the external call to pathconf() which is called by check_ntsec() -- very ugly). I completely agree with the general guidance that these are important checks as it prevents the user from accidentally exposing their private keys. In our environment, the check is returning a false positive given our home directory permissions are tightly controlled (immutable by end users, in fact) and some cross-domain administrative groups are used to delegate control of the directories to certain authorized personnel. Eliminating these groups from the DACL and granting these personnel Backup/Restore rights on the entire filer (hundreds of terabytes) is not a secure solution for us. I'm guessing others in a large corporate environment may find themselves in a similar scenario. I was able to modify the check to work for our scenario and recompile. Obviously this isn't the ideal solution, but it looks like it's our only path forward. I still have to figure out why file ownership isn't recorded properly --- if I figure that out, I'll let everyone know as well. -- 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: Should cygwin's setup*.exe be signed using Sign Tool?
> Has Cygwin considered signing the installer using Sign Tool? More info: > > https://msdn.microsoft.com/en-us/library/windows/desktop/aa387764%28v=vs.85%29.aspx > > http://blog.didierstevens.com/2008/12/31/howto-add-a-digital-signature-to-executables/ > > I believe signing it this way would eliminate the "unknown publisher"; it > would also protect the many people who don't follow the current > signature-checking process. This would create a strong barrier against code > subversion after release. > > The signed executable could also be signed using the current process, so you > don't need to *eliminate* any capability. I can't provide a patch to do > this, obviously :-). > > --- David A. Wheeler Ultimately, this is probably a Corinna question since I believe she compiles the setup executable, but I'll provide my general input as an software developer. Firstly, the tools to sign an executable are certainly available as part of the Windows SDK which is freely downloadable -- so no problem there. However, we would have to determine which publicly trusted certificate to use (using a self-signed cert would likely produce the same message) and is signing the executable the *right* thing to do. Since the setup executable is responsible for running a whole bunch of community contributed post-install executables as part of the installation process, I'm not sure whether it'd be advisable to stamp a particular individual's name or company's name on the executive installer (e.g. Red Hat, for example). If a tainted executable was uploaded into the package repository and subsequently flagged, the certificate authority may have to revoke the certificate which is never good for publicity of the signer. For most pieces of software, the maintainer or the maintainers company's can very confidently vouch for the content of the installation package and executables within it. In the Cygwin world, this accountability is a little more distributed between the package maintainers and source code contributors. That said, I have the upmost respect for the package maintainers and I've never had any security problems with the Cygwin packages other than stupid antivirus false positives and some dirty limericks that got installed (my HR department didn't like that). So that's my two cents. For all I know the *real* reason it's not signed is "nobody had asked for it". - Bryan -- 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: File Permissions - Yet Another Question / Clarification
> He's talking about "Administrators" the SID (group). Interesting. Given the built-in Administrators group doesn't often [directly] play into permissions on remote systems or cross-system permission models, I'm not sure where he was going with that. Regardless, I'll consider it water under the bridge. > In any case, I'd start with a throwaway share (or save the permissions > with subinacl if I had to use a live one). Then remove the inherited / > default DACL from a subdirectory: > > mkdir sub > setfacl -k sub > setfacl -b sub > > Then check how this behaves w.r.t. POSIX permissions and file ownership. > Populate this directory with files and check those, too. The ~/.ssh > directory and their content shouldn't have any DACL on them in any case > if you c want to be sure it works the way sshd is wanting it to. > > > Regards, > Achim. Thanks for advice -- I will give it a shot and dive in deeper. I think I have two problems I'm interesting in understanding more / resolving: 1) why doesn't Cygwin think my user has permissions to the files and 2) how can I get SSH to believe the two "admin" groups on my files are acceptable. I'm not optimistic I'm going to get SSH to change it's behavior so I may need to recompile it to avoid the check which is obviously not desirable from a maintainability standpoint. Appreciatively, Bryan -- 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: File Permissions - Yet Another Question / Clarification
Andrey, >> In the particular case of SSH, is there any way to make SSH ignore >> these permissions? > Thanks, I laughed. Thanks for the less-than-helpful response. A "no" would have sufficed if that is indeed the case. >> and obviously >> causing us pain given the permission weirdness. Removing the >> administrative groups would be undesirable for us since they assist in >> our administrative team doing home directory moves across sites. > Administrators can access anything they want regardless of permissions, if > they really need to do it. > This is not a valid argument. In the real world in large corporations with focus on security, "Administrators" is typically a tiered or least privilege arrangement. All administrators are not created equally. Thanks, Bryan -- 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: File Permissions - Yet Another Question / Clarification
I'll try to reproduce the issue on a standard NTFS volume -- although I would image Cygwin is just decoding the same DACL that ICACLS is returning. The other oddity is why it's not recognizing *me* as having any permissions. In the particular case of SSH, is there any way to make SSH ignore these permissions? I understand the importance / value of the check it's doing, but in our situation, it's not necessary... and obviously causing us pain given the permission weirdness. Removing the administrative groups would be undesirable for us since they assist in our administrative team doing home directory moves across sites. -- 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: File Permissions - Yet Another Question / Clarification
Andrey, Sorry for not being more clear -- yes, I had read the FAQ on SSH. I was taking the problem up a level to the more obvious weirdness demonstrated by the resultant files on a simple "touch". Why would Cygwin report that 'Domain Users' --- a group not in the DACL at all --- as being able to R/W/X on the files? The relevant mount is this: K: on /cygdrive/k type netapp (text,posix=0,user,noumount,auto) Note: It is indeed on a NetApp that is using NTFS mode. -- 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
File Permissions - Yet Another Question / Clarification
I finally am moving my user community to Cygwin 1.7.35 at work and having some issues with ssh not thinking user's ssh keys are owned by the user. I indeed can see that their directory listings do not show their userid as having read,write, or execute to *any* of their files. In short, just wanted to make sure behavior like that demonstrated below is "by design". In particular, I find it odd that "Domain Users" is the only entity that is listed as having permissions despite not being in the DACL at all. On the plus side, the startup speed is much, much faster than before and we no longer need to worry about maintaining our HUGE passwd and groups files. Any thoughts are appreciated. I've read the ntsec page and still digesting all information... @ umask 77 @ whoami bernsbj @ touch mytestfile @ ls -l mytestfile rwx---+ 1 bernsbj Domain Users 0 Apr 1 15:38 mytestfile @ icacls mytestfile mytestfile MYDOMAIN\bernsbj:(I)(F) BUILTIN\Administrators:(I)(F) OTHERDOMAIN\Domain Admins:(I)(F) -- 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: Compatibility of binaries built with one version of cygwin with other versions of cygwin
"Guaranteed" might be a strong word - especially given the lack of a guarantor; probably depends on whether the programmer has had to workaround any nuances in the Cygwin library that may have changed in later versions. I think the library function exports have been the same for awhile and I've personally had pretty good lucking simply dropping in a new DLL file without issues. -- 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: Too Many Permissions Stripped In 1.7.35?
>> Crucial vote starting... now. Given my original post, I'm obviously fan of ignoring SYSTEM (S-1-5-18) explicitly. As much as the absolutist programmer in me doesn't like nuanced exceptions like this, I think it's the pragmatic thing to do. -- 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: Too Many Permissions Stripped In 1.7.35?
> That's an administrator account, not SYSTEM. The BERNS-WINDOWS$ is the account the process was being run under (launched via psexec -i -s) and is indeed the system account. I ran icacls just to display the current ACL on the directory (which does not include the system account for the purpose of the test). Sorry for not being more clear. Regardless, Corinna clarified her assertion was dependent on enabling Backup/Restore privileges for the process at hand. -- 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: Too Many Permissions Stripped In 1.7.35?
> You just have to enable the SeBackupName and SeRestoreName privs. > Try in Cygwin. It does that automatically. > > For cases where you need to stick to the Windows ACLs, use noacl > mounts. Understood --- I can probably set SeBackupPrivilege / SeRestorePrivilege as 'RequiredPriveleges' for the services that depend on the system account having access via the ACLs. Not being used quite in the spirit of those privileges (i.e. for backup/restore), but doable. We'll also have to revise our permissions model on our network filers since before running 'chmod 700' on a file wouldn't blow away our various administrative groups. Like I said originally, just wanted to verify it was desired behavior and it sounds like it is. Thanks! -- 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: Too Many Permissions Stripped In 1.7.35?
> That's not really a goal. The SYSTEM permissions are kind of useless > anyway, given that SYSTEM has permissions to read and write all files > anyway. I don't see that a rule to add SYSTEM permissions to all files > accomplishes anything which isn't already available anyway. I don't think this is true; see below when running as the system account: V:\>echo %USERNAME% BERNS-WINDOWS$ V:\>icacls V:\Test V:\Test DOMAIN\Administrator:(OI)(CI)(F) Successfully processed 1 files; Failed processing 0 files V:\>cd V:\Test Access is denied. V:\> -- 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
Too Many Permissions Stripped In 1.7.35?
I honestly haven't read up exactly how Cygwin interprets NTFS ACL/ACEs, but I remember seeing on the mailing list that a change was made in 1.7.35 was made to permission handling. It is preferable in my organization that the SYSTEM account always have full control the local file system. When using chmod under 1.7.35, it looks like permissions for SYSTEM get stripped (as well as some others). Is this the desired behavior? If so, I'll workaround it somehow but just wanted to verify before we release this much anticipated Active Directory optimized version. For context, I'm running as the default Domain Administrator on a fresh install of Windows 8.1. @@ Testing With 1.7.34 @@ $ uname -a CYGWIN_NT-6.3 BERNS-WINDOWS 1.7.34(0.285/5/3) 2015-02-04 12:14 x86_64 Cygwin $ mkdir TEST-34 $ chmod 750 TEST-34 $ icacls TEST-34 TEST-34 DOMAIN\Administrator:(F) DOMAIN\Domain Users:(RX) Everyone:(Rc,S,RA) BUILTIN\Administrators:(OI)(CI)(F) NT AUTHORITY\SYSTEM:(OI)(CI)(F) BUILTIN\Users:(OI)(CI)(RX) NT AUTHORITY\Authenticated Users:(M) NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)(M) CREATOR OWNER:(OI)(CI)(IO)(F) CREATOR GROUP:(OI)(CI)(IO)(RX) Everyone:(OI)(CI)(IO)(RX) Successfully processed 1 files; Failed processing 0 files @@ Testing With 1.7.35 @@ $ uname -a CYGWIN_NT-6.3 BERNS-WINDOWS 1.7.35(0.286/5/3) 2015-02-25 13:13 x86_64 Cygwin $ mkdir TEST-35 $ chmod 750 TEST-35 $ icacls TEST-35 TEST-35 DOMAIN\Administrator:(F) DOMAIN\Domain Users:(RX) Everyone:(Rc,S,RA) BUILTIN\Administrators:(OI)(CI)(RX) NT AUTHORITY\SYSTEM:(OI)(CI)(RX) BUILTIN\Users:(OI)(CI)(RX) NT AUTHORITY\Authenticated Users:(RX) NT AUTHORITY\Authenticated Users:(OI)(CI)(IO) CREATOR OWNER:(OI)(CI)(IO)(RX) CREATOR GROUP:(OI)(CI)(IO)(RX) Everyone:(OI)(CI)(IO)(RX) Successfully processed 1 files; Failed processing 0 files -- 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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-003 (Christmas/New Year release)
Thanks for the reply, Andrey. I'll take a look at the archives for February. I'm not sure how it'd be "obvious" given that's it's just descriptive metadata for the SID, but I'll try to educate myself before rehashing a previous discussion. -- 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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-003 (Christmas/New Year release)
Finally had a chance to test out the new release, albeit in a very limited fashion. On our multi-domain forest with SID-History enabled, running 'ls -l' was able to lookup account names for groups and users on files. Some ACEs had SIDs that would only be in present SID-History and those worked as well. It would be nice if the names presented would be in what Microsoft calls the "NameSamCompatible" format instead of DOMAIN+USERNAME format. I see this is by design based on the documentation submitted Corinna put together. Not a problem, although I'm curious as to why it was setup this way. -- 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: RFC: 1.7.33 problem with user's home directory
One big vote for the '/etc/nsswitch.conf' idea. I think the truth of the matter is that enterprise environments are way too dynamic (and inconsistent) to attempt to satisfy the majority of configurations with any particular default ordering assumption. Another user brought up a good point about desire for Cygwin to operate in 'read-only' mode -- something that I'd also really love to see addressed. The need for /tmp and /var/log to be 'writable' results in some problems in a high-security environments. This became especially noticeable with Cygwin 64-bit because Windows does not automatically redirect write attempts to %LOCALAPPDATA%\VirtualStore. Anyhow, that's probably left to a different conversation for a different day... -- 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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.6
I haven't tried Cygwin 1.7.33 yet. What would be the expectation of
sidHistory working? In the past, I've had a script to read extra SIDs
out of AD and merge them into passwd.
On Wed, Nov 5, 2014 at 11:43 AM, Corinna Vinschen
wrote:
> Hi Cygwin friends and users,
>
>
> I just released a 6th TEST version of the next upcoming Cygwin release,
> 1.7.33-0.6.
>
> Changes compared to the former test version 1.7.33-0.5:
>
> - The 1.7.33-0.5 version introduced a dependency to a symbol (__dso_handle)
> provided only by GCC versions starting with GCC 4.8.3-3. This results
> in being unable to link executables with GCC 4.8.3-2 and earlier.
> Cygwin 1.7.33-0.6 introduces a fix for this situation by providing its
> own default symbol __dso_handle.
>
>
> If you want to help testing this new release (which I seriously hope
> for), you can find it in your setup-x86.exe or setup-x86_64.exe as
> "test" release.
>
>
> The major change in this new release is the new method to read account
> (passwd and group) information from the Windows user databases directly,
> without the requirement to generate /etc/passwd and /etc/group files to
> generate Unix-like uid and gid.
>
> For your convenience I wrote new documentation. Since this is a TEST
> prerelease, the new documentation is not part of the official docs yet.
> Rather have a look at
>
> https://cygwin.com/preliminary-ntsec.html
>
> If you read it
> (which I seriously hope for) and it's all just incomprehensible
> gobbledygook to you, please say so on the mailing list
>
> cygwin AT cygwin DOT com
>
> so we have a chance to improve the documentation.
>
> Please give this TEST release a try.
>
> If you find problems in the new features or regressions compared to the
> current stable release 1.7.32, please report them to the public mailing
> list
>
> cygwin AT cygwin DOT com
>
>
> Following is a list of changes in this new release:
>
>
> What's new:
> ---
>
> - Cygwin can now generate passwd/group entries directly from Windows
> user databases (local SAM or Active Directory), thus allowing to run
> Cygwin without having to create /etc/passwd and /etc/group files.
> Introduce /etc/nsswitch.conf file to configure passwd/group handling.
>
> For bordercase which require to use /etc/passwd and /etc/group files,
> change mkpasswd/mkgroup to generate passwd/group entries compatible
> with the entries read from SAM/AD.
>
> - Add -b/--remove-all option to setfacl to reduce the ACL to only the
> entries representing POSIX permission bits.
>
> - /proc/cygdrive is a new symlink pointing to the current cygdrive prefix.
> This can be utilized in scripts to access paths via cygdrive prefix, even
> if the cygdrive prefix has been changed by the user.
>
> - /proc/partitions now prints the windows mount points the device is mounted
> on. This allows to recognize the underlying Windows devices of the Cygwin
> raw device names.
>
> - New API: quotactl, designed after the Linux/BSD function, but severely
> restricted: Windows only supports user block quotas on NTFS, no group
> quotas, no inode quotas, no time constraints.
>
> - New APIs: ffsl, ffsll (glibc extensions).
>
> - New API: stime (SVr4).
>
> - Provide Cygwin documentation (PDFs and HTML) for offline usage in
> /usr/share/doc/cygwin-${version}.
>
>
> What changed:
> -
>
> - New internal exception handling based on SEH on 64 bit Cygwin.
>
> - Revamp Solaris ACL implementation to more closely work like POSIX ACLs
> are supposed to work. Finally implement a CLASS_OBJ emulation. Update
> getfacl(1)/setfacl(1) accordingly.
>
> - When exec'ing applications, check if $PATH exists and is non-empty. If not,
> add PATH variable with Cygwin installation directory as content to Windows
> environment to allow loading of Cygwin system DLLs.
>
> - Disable CYGWIN "dosfilewarning" option by default.
> - Improve various header files for C++- and standards-compliance.
>
> - Doug Lea malloc implementation update from 2.8.3 to the latest 2.8.6.
>
> - The xdr functions are no longer exported for newly built executables.
> Use libtirpc-devel instead.
>
> - atexit is now exported as statically linked function from libcygwin.a.
> This allows reliable access to the DSO handle of the caller for newly
> built executables. The former atexit entry point into the DLL remains
> for backward compatibility only.
>
>
> Bug Fixes
> -
>
> - Per POSIX, dirfd(3) now returns EINVAL rather than EBADF on invalid
> directory stream.
>
> - Fix a resource leak in rmdir(2).
>
> - Fix fchmod(2)/fchown(2)/fsetxattr(2) in case the file got renamed after
> open and before calling one of the affected functions.
> Addresses: https://cygwin.com/ml/cygwin/2014-08/msg00517.html
>
> - Handle Netapp-specific problem in statvfs(2)/fstatvfs(2).
> Addresses: https://cygwin.com/ml/cygwin/2014-06/msg00425.html
>
> - Fix chown(2) on ptys in a corner case.
>
> - Generate correct error when a path i
Re: BLODA Addition
Random is this case is receiving a "permission denied" message from the shell when launching an executable. When repeatably running a test case, we see an error one every 15 minutes on average. Without it installed, no error occurs. I'll see what might be good registry key to query -- not sitting at a computer with it installed right now. I was thinking about debugging the underlying issue that's causing this from a cygwin perspective. Would this be advisable or is this behavior just a fundamental consequence of how cygwin interacts with Windows? On Nov 5, 2014 11:43 AM, "Corinna Vinschen" wrote: > > Hi Bryan, > > On Nov 5 11:12, Bryan Berns wrote: > > I recently discovered that the Liquidware Labs Stratusphere Agent > > causes random issues when launching executables through a Cygwin bash > > What means "random issues" here? > > > shell. Any chance someone can add this to the BLODA list to help > > others that might run into similar issues? > > If you can describe a simple way how to discover the software by > the existence of some file or registry key, or maybe by the name > of a running process (not as reliable), we could add this even to > the BLODA test in cygcheck. > > > Thanks, > Corinna > > -- > Corinna Vinschen Please, send mails regarding Cygwin to > Cygwin Maintainer 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
BLODA Addition
I recently discovered that the Liquidware Labs Stratusphere Agent causes random issues when launching executables through a Cygwin bash shell. Any chance someone can add this to the BLODA list to help others that might run into similar issues? -- 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: Necessary To Query SACL Information?
Arg. Responding to myself. Apparently ALL_SECURITY_INFORMATION is internally defined and doesn't contain the flag for SACL information (so much for being 'ALL'). I'll keep exploring... -- 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
Necessary To Query SACL Information?
I noticed when I launch an executable, Cygwin queries SACL information on the executable (which I can see in Process Monitor as a 'QuerySecurityFile' operation). On some of my protected file servers, this generates a failure audit. Looking at the source code, I'm going to guess this might be from the NtQuerySecurityObject call in security.cc which requests SACL information by asking for for ALL_SECURITY_INFORMATION. Does Cygwin really need to query this information? Aside from keeping my audit logs clean, it seems like it might be an opportunity for optimizing the executable launch process if Cygwin doesn't really need this (or some of the other information that ALL_SECURITY_INFORMATION provides). Thoughts? -- 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
