Re: ls/stat on OneDrive causes download of files
On 3/8/2024 7:52 AM, Thomas Wolff via Cygwin wrote: Am 08.03.2024 um 11:37 schrieb Corinna Vinschen via Cygwin: Hi Jeffrey, On Mar 6 13:55, Jeffrey Altman via Cygwin wrote: On 3/6/2024 12:19 PM, Corinna Vinschen via Cygwin wrote: We can add an explicit call to RtlSetProcessPlaceholderCompatibilityMode (PHCM_EXPOSE_PLACEHOLDERS); [...] Files and directories that are placeholders should have either the FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS or FILE_ATTRIBUTE_RECALL_ON_OPEN file attributes set. When these attributes are set, applications and mini filters are advised not to "read" or "open" the files or directories unless they absolutely need to because doing so will cause the placeholder to be replaced by an object containing the actual data which might take a long time to fetch, Yesterday I stumbled over a certain NtCreateFile flag: FILE_OPEN_NO_RECALL (0x0040) Instructs any filters that perform offline storage or virtualization to not recall the contents of the file as a result of this open. MS-CIFS described it like this: FILE_OPEN_NO_RECALL 0x0040 In a hierarchical storage management environment, this option requests that the file SHOULD NOT be recalled from tertiary storage such as tape. A file recall can take up to several minutes in a hierarchical storage management environment. The clients can specify this option to avoid such delays. This sounds like we could simply add this flag to all NtOpenFile used for path conversion or stat-like calls, without having to care for any file attributes specificially. Does that make sense? Sounds good, without even studying the other details... I speculate some more handling would still be needed to avoid executable detection via magic tags. Agreed. FILE_OPEN_NO_RECALL has been defined for at least a decade but was not documented by Microsoft relatively recently. Another suggestion would be to try opening the file with FILE_READ_ATTRIBUTES instead of GENERIC_READ if the file data is not required. See https://github.com/microsoft/BuildXL/commit/4fb8e7ce07d243ccd95de0d66da551538a794493 Jeffrey Altman -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: ls/stat on OneDrive causes download of files
On 3/6/2024 12:19 PM, Corinna Vinschen via Cygwin wrote: We can add an explicit call to RtlSetProcessPlaceholderCompatibilityMode (PHCM_EXPOSE_PLACEHOLDERS); and we can recognize the IO_REPARSE_TAG_FILE_PLACEHOLDER and IO_REPARSE_TAG_CLOUD_* tags during symlink evaluation, but even then we still have to know what the reparse point buffer actually contains. Given that the content of reparse points with these reparse tags are undocumented, some people using cloud services should examine these reparse points so we can add some suitable code to Cygwin. Corinna I'm not an expert in this area by any means but here are my recollections from when Microsoft presented in-person on cloud placeholders to filter and filesystem developers many years ago. Files and directories that are placeholders should have either the FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS or FILE_ATTRIBUTE_RECALL_ON_OPEN file attributes set. When these attributes are set, applications and mini filters are advised not to "read" or "open" the files or directories unless they absolutely need to because doing so will cause the placeholder to be replaced by an object containing the actual data which might take a long time to fetch, might cost the end user money, or might fail depending upon the network connectivity. In particular, anti-malware should ignore them during scans and only analyze the data when it is fetched locally by an end user application. I believe that IO_REPARSE_TAG_FILE_PLACEHOLDER was replaced by IO_REPARSE_TAG_CLOUD_1 ..IO_REPARSE_TAG_CLOUD_F. Any reparse tag attached to a placeholder object is for the interpretation of the filter associated with the back-end storage and not for the consumption of applications. The content of the reparse tags can be back-end proprietary; different reparse data for onedrive, icloud, dropbox, etc. The default ProcessPlaceholderCompaibilityMode is PHCM_EXPOSE_PLACEHOLDERS which makes the FILE_ATTRIBUTE flags and reparse tags visible. Microsoft maintains a database of processes for which PHCM_DISGUISE_PLACEHOLDER is set which hides that information. Its unclear to me that explicitly setting the placeholder compatibility mode is useful. I'm not sure that exposing the object as a symlink is a good idea. A posix symlink is an object whose type and target information cannot change. In the case of a placeholder, the placeholder is silently replaced by the actual object either when the object is opened or the object's data is accessed. An application that believes it knows that the object is a symlink will be mighty confused when it turns out to be a file or a directory. Perhaps the question that needs to be asked is whether there are opens that can be skipped if an object is known to not be locally present (either of the FILE_ATTRIBUTE flags are set)? Jeffrey Altman -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin generates syscalls for *.lnk files on filesystems with native symlink support?
On 1/8/2024 1:44 PM, matthew patton via Cygwin wrote: Cygwin does not create symlinks as junctions. No idea where you got that idea. $ echo $CYGWINwinsymlinks:nativestrict $ /usr/bin/ln -s default.GGG6q test1 01/08/2024 01:24 PM test1 [...]Type=File $ (unset CYGWIN; /usr/bin/ln -s default.GGG6q test2.nocygwin) 01/08/2024 01:25 PM test2.nocygwin [...]Type=File JUNCTIONS are a type of reparse point tag. Many tools report things as JUNCTIONS when they don't know what else to call it because JUNCTIONS were the only type of reparse tag commonly used. This is the output of JP Software's Take Command for an AFS volume root directory [\\afs\yfs]dir Directory of \\afs\yfs\* 5/26/2021 11:49 . 11/26/2019 14:25 amd64_linux26 [your-file-system.com#amd64_linux26] 11/24/2019 20:29 backups 10/20/2022 10:43 project 12/05/2011 10:14 public [#root.public] 9/06/2020 9:27 service 7/26/2010 20:44 support [#root.support] 6/15/2011 11:40 test [#test.test] 2/15/2012 8:49 u 3/28/2023 12:50 user 11/28/2011 17:01 usr [user] 12/10/2009 0:34 www [#root.www] 12/13/2016 1:29 30 autorun.inf 6/07/2015 21:54 104 Desktop.ini 11/26/2019 14:42 local [@sys\usr\local] 148 bytes in 3 files and 12 dirs 0 bytes free The JUNCTIONS are AFS volume mount points using the Microsoft designated reparse point for OpenAFS. The SYMLINKD is a symlink reparse point to a directory using the NTFS symlink reparse point. The SYMLINK is a symlink reparse point to an object of unknown type (which Windows expects to be a file not a directory) using the NTFS symlink reparse point. Here is the cygwin ls -l output [\\afs\yfs]c:\tools\cygwin\bin\ls -l . total 38 -rw-r--r-- 1 jaltm mkpasswd 104 Jun 7 2015 Desktop.ini drwxr-xr-x 1 jaltm mkpasswd 0 Nov 26 2019 amd64_linux26 -rw-r--r-- 1 jaltm mkpasswd 30 Dec 13 2016 autorun.inf drwxr-xr-x 1 jaltm mkpasswd 0 Nov 24 2019 backups lrwxrwxrwx 1 jaltm mkpasswd 14 Nov 26 2019 local -> @sys/usr/local drwxr-xr-x 1 jaltm mkpasswd 0 Oct 20 2022 project drwxr-xr-x 1 jaltm mkpasswd 0 May 21 2023 public drwxr-xr-x 1 jaltm mkpasswd 0 Sep 6 2020 service drwxr-xr-x 1 jaltm mkpasswd 0 Nov 17 2015 support drwxr-xr-x 1 jaltm mkpasswd 0 May 26 2019 test drwxr-xr-x 1 jaltm mkpasswd 0 Feb 15 2012 u drwxr-xr-x 1 jaltm mkpasswd 0 Mar 28 2023 user lrwxrwxrwx 1 jaltm mkpasswd 4 Nov 28 2011 usr -> user drwxr-xr-x 1 jaltm mkpasswd 0 Jul 10 2017 www As part of this reply I will note that the NTFS symlinks differ from POSIX symlinks in significant ways 1. A pre-existing file system object is required in order to attach a reparse tag 2. The type of the target must be known when the reparse tag is applied to a pre-existing file system object 3. The reparse tag may be removed and replaced any number of times without deleting the pre-existing object to which it is attached. Whereas a POSIX symlink inode target cannot be altered once created. The inode must be deleted and replaced. 4. The Windows file APIs do not behave as many applications expect them to when a symlink reparse tag is present. For example, opening a file handle will traverse the reparse tag and open the target but the file info api when given the same path will return the information belonging to the object on which the reparse tag was applied. This breaks many applications such as the java runtime among others. Jeffrey Altman -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin/Win32 utility function to convert "raw" IPv6 address string into *.ipv6-literal.net string ?
On 9/28/2023 1:56 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote: What do you think that output is - the PTR is resolved to "localhost." You obviously did not get the point that I was making. Using ip6.arpa *is* the standard way to get around with "DNS-like" IPv6 addresses, as it would be "understood". Using the "ipv6-literal.net" domain is not portable and would result in NXDOMAIN anywhere but Windows (where the resolver seems to intercept and convert them internally). The ip6.arpa names are used to lookup PTR records which contain hostnames. The ipv6-literal.net names are used to simulate records and map the name to an IPv6 address (with an optional address scope). For those that are unaware of the history[1][2][3], UNC names support the use of IPv4 addresses as an alternative to SMB server names or DNS host names. End users expect to be able to specify a UNC path such as \\2001:db8:85a3:8d3:1319:8a2e:370:7348\share or \\[2001:db8:85a3:8d3:1319:8a2e:370:7348]\share However, colons are illegal in UNC paths and therefore standard IPv6 representations cannot be used. The .ipv6-literal.net server name is a method of representing an IPv6 address as a UNC server name such that it can be locally translated by getaddrinfo() into an IPv6 address without querying DNS. \\2001-db8-85a3-8d3-1319-8a2e-370-7348.ipv6-literal.net\share If the ipv6.arpa representation\\8.4.3.7.0.7.3.0.e.2.a.8.9.1.3.1.3.d.8.0.3.a.5.8.8.b.d.0.1.0.0.2.ip6.arpa\path was used as a server name and treated as a DNS lookup that would be harder for humans to construct and no more portable. The ip6.arpa representation would also be unable to represent IPv6 address scopes which are supported by ipv6-literal.net names. I am unaware of any Microsoft Windows APIs that can be called to translate from an IPv6 address to an ipv6-literal.net string. [1] https://en.wikipedia.org/wiki/IPv6_address#Literal_IPv6_addresses_in_UNC_path_names [2] https://devblogs.microsoft.com/oldnewthing/20100915-00/?p=12863 [3] https://learn.microsoft.com/en-us/windows/win32/api/winnetwk/nf-winnetwk-wnetaddconnection3a smime.p7s Description: S/MIME Cryptographic Signature -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [EXTERNAL] Re: mkfifo: cannot set permissions of 'x.fifo': Not a directory
On 8/22/2023 10:52 AM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote: FIFOs which don't make *any* sense ... FWIW, a remote NFS fileystem. I got an impression that the OP is trying to deploy something (maybe the entire Cygwin) onto an NFS share. So the named FIFO "file" is also created in there. It's pointless to assume that the FIFO can be used as a communication device between the hosts that can mount the share, but it can be quite feasible to envision a scenario, in which the same host opens the FIFO located on the share from two processes and establish the communication using that special "file" (which is basically a special data-less i-node). I've been following this thread with quite a bit of curiosity. For those who do not know me, I'm the lead developer of the AFS filesystem on Windows. There have been requests for more than two decades for AFS clients to add support for locally created pipe files because AFS volumes are often used as home directories (even on Windows) and so many applications allocate a pipe in the home directory as a method of inter-process communication or a lock. The problem is that even if the intended usage of the file is entirely local, the directory object, the directory entry and the allocated inode (or equivalent) is network visible. What happens when the user executes two copies of an application such as PyCharm on two separate machines sharing the same home directory? Does the directory entry and inode get reused on startup and/or deleted on exit? How does that impact the process instance on the other machine? The conclusion I came to long ago is that if pipes are to be implemented in a network file system namespace then the pipes must be fully functional network pipes. In just about all cases applications can be configured to use a non-default paths. In my opinion they should not be placed in a shared file system. I've also been following this thread because both the Microsoft NFSv3 and the Citi NFSv4 clients are rather incomplete filesystem implementations from the perspective of the Installable File System interface and the Multiple UNC Provider interface. In my opinion, Microsoft NFSv3 is the bare minimum that must be implemented for Microsoft to advertise that NFSv3 is available on Windows. The NFSv3 symlink interface leveraging extended attributes as a method of setting and reading the target predates the introduction of IO_REPARSE_TAG_SYMLINK for NTFS. Prior to the allocation of IO_REPARSE_TAG_SYMLINK I obtained a proprietary tag allocation from Microsoft for AFS symlinks but switched to IO_REPARSE_TAG_SYMLINK once it was available because then AFS symlinks work the same as NTFS. The Citi NFSv4 implementation is not only incomplete from a Windows interface perspective but Citi never obtained from Microsoft the required filesystem registrations. For example, it doesn't have a Microsoft assigned FLT_FILESYSTEM_TYPE, WNNC network type, name or NodeTypeCode values. FLT_FSTYPE_NFS, WNNC_NET_MS_NFS, and "nfs" are specific to the Microsoft NFSv3 (aka \FileSystem\NfsRdr) implementation. The NodeTypeCode range used by the Citi NFSv4 filesystem (0xFC00) is outside the block allocated to third party filesystems and appears to be from a published sample which could lead to corruption if two filesystems allocating FileControlBlocks with the same NodeTypeCodes are present on the system. The returned WNNC value is also from a sample. Perhaps the original poster knows where development of the Citi NFSv4 client is currently taking place. The source code repos I've been able to find do not have any commits since 2012 (tag v1.0.0) and have been flagged as archival on GitHub. In my opinion, for Cygwin to reliably work with either of these implementations is going to require on-going developer effort and continuous integration testing. Not only of Cygwin but in the case of Citi NFSv4 from the team maintaining the product. Unless something has significantly changed since 2013 I do not expect Microsoft to be willing to invest much effort into enhancing the NFSv3 implementation. The likely recommendation would be to re-export the NFS file shares via Samba and access them via CIFS. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Native symbolic link behavior is broken and makes backups using Cygwin command line tools impossible
On 1/4/2021 10:27 AM, Matt D. via Cygwin (cygwin@cygwin.com) wrote: > I am using symbolic links native to Windows. My CYGWIN environment > variable has been set to "winsymlinks:nativestrict" and my account has > permission to make symbolic links. This is an issue specifically with > Cygwin; I have no problems making links at the windows command line. > Cygwin also does not have a problem making symbolic links-- if the > target already exists. The issue is that I cannot create native > symbolic links with Cygwin for targets that DON'T exist. > > The normal behavior for both Windows and Linux is to create the > symbolic link whether the target exists or not. I don't know why > Cygwin fails to do this only for native Windows symbolic links. It > does not have a problem creating links to any target with the default > Cygwin (non-Windows) symbolic links. Windows native symlinks encode the object type of the target and the encoded type must match that of the target or the link will not work when the target exists. A UNIX symlink does not encode any details of the target. Cygwin doesn't know what type of native symlink to create if the target does not exist. I hope this knowledge helps. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Compiling C-Kermit 9.0.305 Alpha.02 on Cygwin
On 11/30/2020 10:06 AM, Keith Christian via Cygwin (cygwin@cygwin.com) wrote: > I downloaded the .tar.gz of C-Kermit 9.0.305 Alpha.02, 19 September 2020. > Web page: http://www.kermitproject.org/ckdaily.html > Source download: http://www.kermitproject.org/ftp/kermit/test/tar/x.tar.gz > > I realize that C-Kermit has not been in the Cygwin distribution for > awhile. There is no "cygwin" target in the makefile in the x.tar.gz > source distribution. > Is there any guidance for how to compile this modern version of > C-Kermit for present-day Cygwin? > > Thanks. I suspect building C-Kermit with SSH, OpenSSL, Kerberos v5 support is going to be problematic since none of that code has been updated in more than a decade to keep up with the latest upstream packages. I suggest you start by trying to build for a generic linux target without any security features. Jeffrey Altman former Kermit developer smime.p7s Description: S/MIME Cryptographic Signature -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: My delayed complaint about spam on this list
On 6/4/2018 4:13 PM, Frank Farance wrote: > Second, as a mailing list admin myself, at some time we're going to have > to deal with spam as some of the members E-mail systems will start > tagging normal cygwin stuff as spam, which is the kind of stuff members > don't have control over in medium-to-large organizations. My mail servers regularly categorize cygwin at cygwin.com mail as spam. And then there is all of the mail that simply gets rejected because of DMARC policies applied by the sender's domain. > (1) getting rid of spam by restricting senders to members of the list > (which, as you state, might lose people like you) > > versus > > (2) reducing spam for the 1500 members on the list (yet still lose you > because you need to become a member of the list to see the responses > from others), There are other alternatives. I'm a member of a few mailing lists that accept e-mails from non-list members but only after the non-list member successfully accesses a URL that is mailed to the sender's address. Would something like that be possible for the cygwin lists? Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Windows 10 Creators Update and Symlinks
When Developer mode is enabled the elevation requirement for symlink creation is disabled: https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10/#DXz6icKZOkEozgYR.97 This was necessary for symlink creation within WSL to work. smime.p7s Description: S/MIME Cryptographic Signature
Re: Problem with chdir and GetCurrentDirectory on Windows 2016
On 12/7/2016 3:23 PM, Dipak Gaigole wrote: > GetCurrentDirectory returned <C:\Pro>, ret = <6> GetCurrentDirectory failed with ERROR_INVALID_HANDLE. As a result the buffer was not populated. What is in dirname[] is stack garbage. My guess is that /cygdrive/c/Program Files is not associated with a device or if it associated with a NTFS device the driver doesn't know how to match /cygdrive with a valid path. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: FUSE, symbolic links and special files
On 8/25/2016 11:21 AM, Corinna Vinschen wrote: > On Aug 25 10:46, Jeffrey Altman wrote: >> On 8/25/2016 9:16 AM, Corinna Vinschen wrote: >>> On Aug 25 09:04, Jeffrey Altman wrote: >>>> On 8/25/2016 8:45 AM, Corinna Vinschen wrote: >>>>> Since when is this RP method available? Unfortunately the above MSDN >>>>> page doesn't tell... Was it already available with Vista? Does anybody >>>>> know? >>>> >>>> #define IO_REPARSE_TAG_NFS >>>> >>>> was added in the Windows 8.0 DDK. >>> >>> Thank you. Too bad, so we have to stick to the EA method to accommodate >>> Vista and W7. >> >> I don't believe there is any restriction from using this tag on Vista or >> Win7. It will be stored on NTFS just as any other Reparse Tag would be. >> NTFS and ReFS will ignore it just as they would on Win8 or Win10. > > Sorry, but I don't grok that. Why would I create a reparse point on > NTFS with this value? This RP type would only be interesting if I can > access the information for files on a non-Windows remote filesystem to > indicate special file types. If you want the underlying remote file system to parse the value then you can't set it anywhere except on the file system that returns protocol type WNNC_NET_MS_NFS 0x0042 because that is the only file system for which it is known supports the Microsoft reparse tag IO_REPARSE_TAG_NFS (0x8014L) Since it is a Microsoft TAG it means that it can be interpreted by any file system. For example, I could add support for it to OpenAFS as an alternative method of creating and reporting symlinks instead of IO_REPARSE_TAG_SYMLINK (0xA00CL) or IO_REPARSE_TAG_OPENAFS_DFS (0x0037L) Only one of the reparse tag types can be reported at a time so the choice of which reparse tag to use could be left up to configuration or be set via an FSCTL on a per process basis. Ideally Cygwin would obtain its own IO_REPARSE_TAG_ value to use and then any file system that wants to support Cygwin can simply add support for it. Whether that be FUSE or OpenAFS or an NFS implementation, etc. FUSE should also be sure to obtain its own WNNC_NET_ value to use. > Granted, it *could* be used by Cygwin on NTFS to indicate Cygwin's own > implementations of AF_LOCAL sockets or fifos. Or even for symlinks. > But that would only introduce YA symlink type which would be unusable > from non-Cygwin applications. Correct. With its own reparse tag Cygwin could store exactly the same metadata it stores today in the data stream of the .lnk file as reparse tag data. The benefit of applying a reparse tag is that the .lnk will no longer be confused for a regular file. On file systems that do not support reparse points it can continue to store the data in the data stream. > Or am I missing something? I doubt it. > > Thanks, > Corinna Anytime. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: FUSE, symbolic links and special files
On 8/25/2016 9:16 AM, Corinna Vinschen wrote: > On Aug 25 09:04, Jeffrey Altman wrote: >> On 8/25/2016 8:45 AM, Corinna Vinschen wrote: >>> Since when is this RP method available? Unfortunately the above MSDN >>> page doesn't tell... Was it already available with Vista? Does anybody >>> know? >> >> #define IO_REPARSE_TAG_NFS >> >> was added in the Windows 8.0 DDK. > > Thank you. Too bad, so we have to stick to the EA method to accommodate > Vista and W7. I don't believe there is any restriction from using this tag on Vista or Win7. It will be stored on NTFS just as any other Reparse Tag would be. NTFS and ReFS will ignore it just as they would on Win8 or Win10. The only file system for which this tag is known to be interpreted is the Microsoft NFS provider that will report its FILE_REMOTE_PROTOCOL_INFORMATION.Protocol value as #define WNNC_NET_MS_NFS 0x0042 Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: FUSE, symbolic links and special files
On 8/25/2016 8:45 AM, Corinna Vinschen wrote: > Since when is this RP method available? Unfortunately the above MSDN > page doesn't tell... Was it already available with Vista? Does anybody > know? #define IO_REPARSE_TAG_NFS was added in the Windows 8.0 DDK. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: FUSE for Cygwin
On 6/22/2016 3:43 PM, Bill Zissimopoulos wrote: > > The bigger question is whether the Cygwin community would want a package > like this. The obvious answer might be yes (I hope), but there is a large > caveat. WinFsp includes a kernel-mode driver that needs to be built using > Microsoft tools and signed using an EV certificate. In fact it looks like > those requirements will only get harder as time passes -- soon we may need > a sysdev account just to sign drivers. This means that the familiar model > of getting the source and compiling everything using Cygwin tools cannot > work here. I believe that as of Windows 10 Anniversary Edition and Server 2016 Secure Boot becomes mandatory for new installations and with Secure Boot comes the requirement that all device drivers (including file system drivers) be signed by Microsoft. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: FUSE for Cygwin - was: Re: Fork and Windows Heap
On 6/18/2016 4:03 PM, Bill Zissimopoulos wrote: > * A directory cannot be renamed if it or any of its subdirectories > contains a file that has open handles (except in the batch-oplock case > described earlier). > > > In particular the third bullet point mandates that the FSD keeps > information not only about files that are open, but also of their > hierarchical relationships. The easiest way to do this on Windows is to > maintain a mapping of file names to open files. This is not how my file system redirector enforces the rule. The file control block (representing the handle) for an open file maintains a reference to the directory object through which it was opened. As long as the directory object has outstanding references the redirector fails the rename request. File path maps to specific files in fact do not work because the file can be hard linked into more than one directory. Only the directory that was used to create a file handle is restricted from renaming. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: BSOD when running from network share
On 11/19/2015 5:13 PM, Patrick Herbst wrote: > As soon as i hit enter on "EOF" I get a BSOD RDR_FILE_SYSTEM STOP: 0x0027 The full error context can be determined by turning on Full Memory Dumps and then reproducing the error. A MEMORY.DMP file will be written to the %SystemRoot%\Windows directory. You can load that file into windbg.exe aka Debugging Tools for Windows which would need to be downloaded and installed. Use the "!analyze -v" command within windbg.exe to generate the full context of the kernel exception. It will tell you which device driver is at fault and what the full stack is. > Can anyone else > 1) reproduce this? Doesn't really matter since you can. The ability to reproduce a kernel exception can be dependent on any number of environmental factors. > 2) confirm this? > 3) fix this? Only the author of the device driver that is crashing will be able to fix it. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: Error accessing mapped drive >2TB?
by reusing the IO_REPARSE_TAG_SYMLINK tag since they do not expose the reparse data for symlinks. ]dir r:\ Directory of R:\* 10/23/2015 9:21. [R:\.] 10/23/2015 9:21.. [R:\..] 10/01/2015 18:56afs [R:\afs] 10/22/2015 18:53 Applications 7/21/2011 22:15 Incompatible Software 10/22/2015 14:04 Library 10/22/2015 14:06 System 9/30/2015 8:33 Users 1/24/2011 23:27 User Guides And Information [\Library\Documentation\User Guides and Information.localized] 0 bytes in 1 file and 8 dirs 60,172,144,640 bytes free ]getfileinfobyhandle.exe "r:\User Guides And Information" Attribute: 0x420 Archive Reparse Point ReparseTag: 0xa00c Microsoft Surrogate Size: 0x0:0 EOF: 0x0:0 Links: 1 Delete?no Directory? no You might also not that Apple does not expose volume serial numbers. So the serial number on either side of a mount point will always be zero. ]getvolumeinfobyhandle.exe r:\afs\ File System: NTFS Volume Name: Macintosh HD Serial: 0 Max Component Length: 255 System Flags: 0x40086 Case Preservation Named Streams Supports Reparse Points Unicode on Disk Therefore, applications cannot rely on the serial numbers to distinguish between devices. Instead, the applications must do as the Explorer Shell does and track the locations of the RP attributes in paths as they are encountered. Remember that there is no requirement that SMB servers expose reparse points at all nor is there any requirement that they expose volume information. While Apple's design choices do not fit with the expectations of Cygwin they are not necessarily wrong. I hope this e-mail is helpful. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: diff -r won't recurse
On 4/4/2015 3:27 PM, lemke...@t-online.de wrote: Clutching at straws (note the identical serial number, does it confuse Cygwin?): orion /usr/lib/csih/getVolInfo.exe /g Device Type: 7 Characteristics: 20 Volume Name: ND D (HDD) Serial Number : 3357258338 ... orion /usr/lib/csih/getVolInfo.exe /d Device Type: 7 Characteristics: 20 Volume Name: ND D (HDD) Serial Number : 3357258338 This was it. I changed the Volume Serial Number with a Sysinternals tool (https://technet.microsoft.com/en-us/sysinternals/bb897436.aspx) and after a reboot diff now recurses into the directories in question. Now is this a Cygwin bug or am I doing something terribly unsupported? The serial number is used by many tools to track the volumes that are crossed by reparse points to ensure that a loop does not occur. I suspect that in this case the tool is concluding that the reparse point is referring back to the same volume. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: cygwin texinfo 5.2.2 missing makeinfo.exe
On 3/28/2015 9:12 AM, Achim Gratz wrote: Jeffrey Altman writes: After installing the texinfo 5.2.2 and texinfo-tex 5.2.3 packages I am unable to find an installed makeinfo command in /usr/bin/. I do however find the makeinfo.1.gz man page contents. makeinfo should be a symbolic link to texi2any. Regards Achim. Thank you Achim, The symbolic link works from a Cygwin bash shell but not from a Windows cmd or powershell. texinfo 4.7.* had a separate makeinfo.exe which was used by the native Heimdal build environment to generate docs from Microsoft nmake.exe. 4.7.* is still available for 32-bit Cygwin but is not available for 64-bit Cygwin. At least I now know what the issue is. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
cygwin texinfo 5.2.2 missing makeinfo.exe
After installing the texinfo 5.2.2 and texinfo-tex 5.2.3 packages I am unable to find an installed makeinfo command in /usr/bin/. I do however find the makeinfo.1.gz man page contents. This is using a new install of Cygwin64. Is this an oversight? Any work arounds? Thanks for all of the hard work that is put into maintaining Cygwin and packages for it. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: /usr/local, /var and */tmp in c:\Users\Public
On 11/15/2014 12:55 PM, Lee wrote: So, just because I installed Cygwin with my regular user account, You're doing it wrong. Install Cygwin using an admin account and regular user accounts are not allowed write access to system files/directories: This feels really wrong to me. If installing Cygwin under a non-admin account results in a potential security vulnerability, then the installer should be taking that into account. Applications that behave differently depending upon how they are installed should have in the installer an option for * install for all users (requires administrator) * install for the current user Where install for current user installs the application configured so that the current user account (and not others) can use it. Just my two cents. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: RFC: 1.7.33 problem with user's home directory
On 11/11/2014 4:59 AM, Corinna Vinschen wrote: Please keep in mind that I'm talking about the Cygwin home dir not as a default value which can be overridden in /etc/passwd, but of a Cygwin home dir as returned by Cygwin when fetching the passwd entry from AD, and no passwd file exists. This Cygwin home dir should be: - Make some kind of sense when using a default value. - Be configurable by the administrators if possible. That's why I thought it a good idea to utilize unixHomeDirectory. Default is /home/$USER, The admins can set it to some other value in POSIX notation. Using the unixHomeDirectory feels wrong to me because it doesn't provide a context to indicate where the home directory is located. Its intended purpose is to permit the specification of the home directory for UNIX systems. On a UNIX system it might be a local disk or /home might be on one or more network file systems which might or might not be accessible from a Windows system. What would the behavior be if unixHomeDirectory was /afs/example.edu/users/j/e/jeff and no AFS client was installed on the Windows system? What would the behavior be if there was an AFS client installed on the Windows system? To access AFS from Windows would require UNC notation not an absolute root. Does a default location in the Windows profile make sense and permit administrators to provide HKCU\SOFTWARE\Cygwin\ registry value to indicate an alternative location? Or perhaps a per-user environment variable which would also be distributed via the user's registry hive. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: RFC: 1.7.33 problem with user's home directory
On 11/10/2014 3:52 PM, Corinna Vinschen wrote: Hi, after a long discussion in RL today, I came to the conclusion that there's a major problem in the current handling of the user's home directory in AD environments in the new user account code when not using /etc/passwd files. My personal preference would be for the Cygwin Home directory to be created under %HOMEPATH%\AppData\Roaming\Cygwin That way the home directory is isolated from native windows applications that might use the same file names but with different line endings directly in %HOMEPATH%. And, the data is within the user profile so that when accessed via redirection or otherwise, the data is accessible on every machine the user logs into. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: The eternal uid issue
On 7/24/2014 5:42 PM, D. Boland wrote: Hi Corinna, Corinna Vinschen wrote: But be careful. Just because there are multiple users with admin permissions, that doesn't mean they all want their mail in the same mailbox for user 0... Things are actually worse than Corinna and others have described. The SYSTEM account is a built-in local machine account that by default is granted certain permissions but those permissions are configurable. There is a built-in Administrator account which everyone is taught to never use There are two default groups Administrators and Domain Administrators whose members are considered to be administrators but whose logon sessions run in a restricted mode which is tighter in many regards than standard users UNLESS the process running as that user is granted elevated access. Simply working off the user's SID or GIDs to make decisions are often going to result in failures that appear to your users as unpredictable. Thanks for the overloading code. I already tested it. Now I can leave the Sendmail code (almost) unchanged. Thanks also for the time you put into this. I hope the RedHat people pay you well. I have Sendmail ready to be released, but only the 'crude' version (running as an admin user). I'd like to go for the preferred solution (starting as admin, switching to unprivileged). The uid issue is sorted. But to get it there, I have one final problem to solve. On all modern versions of Windows the accounts that are members of the Administrators and Domain Administrators accounts are going to run unprivileged. In the Windows world background daemons (aka services) should be assigned their own service account that is granted the minimum set of privileges required. Windows permissions are much more fine grained than POSIX and this gives you a great deal of control. Shedding privileges can be done by a privileged process by replacing its process (or thread access tokens) with a more restricted version. Sendmail checks if the user's home directories are group- or world writable. It does this with 'stat'. If Sendmail is running in 'crude' mode (main program and children running as the Sendmail 'smmsp' user, made admin), stat returns the right file mode for my home directory (rwxr-xr-x). The email is delivered. On Windows file systems (as with many UNIX network file systems, think AFS as one example) the UNIX mode is not going to have much value. What matters are the entries in the access control list and that is what should be checked and manipulated. Cygwin can't turn a non-POSIX file system into a POSIX file system no matter how hard it tries. If I have Sendmail running in preferred mode (main program as cyg_server, children running as 'smmsp', removed from admin group), stat returns the wrong mode (rwxrwxrwx). As a consequence, Sendmail refuses to deliver email. The UNIX mode cannot describe the fine grained permissions of the access control language for the file system. Can I do anything about this? Other members of this group might have some additional suggestions on how to remove checks but if you really want secure delivery of e-mail on a Windows file system you will need to write code that is capable of understanding the capabilities of the file system. Just as you would on UNIX if the home directory was in a network file system that relied upon GSS/Kerberos network credentials and Access Control Lists instead of UNIX mode for access control. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: Coverity Scan
On 5/16/2014 4:00 PM, David Stacey wrote: OK - we're in! You can find our project page at https://scan.coverity.com/projects/2250. Off the list, I've sent e-mails to Corinna and CGF inviting them to join the project ;-) gold star? smime.p7s Description: S/MIME Cryptographic Signature
Re: Unable to delegate credentials from Cygwin ssh client was Re: Heimdal 1.5.2: unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10
On 6/25/2013 1:23 AM, Nogin, Aleksey wrote: Jeffrey Altman wrote: I am running Heimdal's kinit (as came with MobaXterm 6.2) under Windows 7 to get a ticket from a Windows AD, and then ssh'ing into RHEL 5 and 6 boxes set up to use pam_krb to authenticate against the same Windows AD. gssapi-with-mic authentication succeeds, but credential delegation does not, and I see the same unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10 error(**) previously reported. This is an issue in my environment, where Kerberos-secured NFS is used to provide access to home directories. One thing I did notice is that when I ssh into an RHEL box, afterwards kinit on the client (Cygwin) side shows a ticket for the RHEL host (as expected), yet it shows that the ticket lacks the forwardable flag, which would probably explain the failure to delegate credentials. So perhaps this is a problem with the SSH client on the Cygwin end (ssh - V reports OpenSSH_6.1p1, OpenSSL 1.0.1c 10 May 2012), rather than Heimdal's? The libdefaults section in krb5.conf on Cygwin does contain forwardable = yes and in contract to how it happens on Cygwin, the Linux-Linux ssh that does delegate credentials correctly also does obtain a forwardable ticket on the client side. Going back to the original posting. The Heimdal that is being used is MobaXTerm's kinit. What Heimdal is it? kinit --version reports kinit (Heimdal 1.5.2). That said, things look exactly the same with plain Cygwin (which reports the same version of Heimdal) [snip] If it is the Cygwin binary then it will be linked against cygwin1.dll. If it is the native binary it will contain resource information visible in the explorer shell and if it came from the Secure Endpoints package will be digitally signed. The Heimdal distribution matters because it will determine where the krb5.conf configuration file is going to be stored. If you aren't sure, use SysInternals Process Monitor to trace the kinit.exe process and see what files it accesses. The configuration is stored in /etc/krb5.conf (behavior changes depending on the contents of that(. I am using the exact same krb5.conf that works correctly on RHEL. When kinit is executed, is the -f parameter provided requesting a forwardable ticket granting ticket? No, but I have forwardable = yes under [libdefaults] in krb5.conf. I can run klist -vvv and I see that the flags are as follows: Server: krbtgt/REALM@REALM Client: anogin@REALM [...] Ticket flags: pre-authent, initial, renewable, forwardable Addresses: addressless Server: host/sshserver@REALM Client: anogin@REALM [...] Ticket flags: pre-authent Addresses: addressless Again, the above is the same with plain Cygwin. The TGT issued to your principal is forwardable but the host/fqdn@REALM principal is not. There are four possibilities: 1. sshd is not properly requesting a forwardable ticket 2. a request to the KDC is being issued with the forwardable flag but the KDC is refusing to issue a forwardable ticket because: a. The krbtgt/REALM@REALM service principal does not permit forwarding b. The host/fqdn@REALM service principal does not permit forwarding 3. a bug in Heimdal where the forwardable flag is not set when it should be. I would start by using wireshark to examine the requested tickets and the response. -- 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: Packaging Heimdal for Cygwin was Re: Heimdal 1.5.2: unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10
On 6/24/2013 5:10 AM, Corinna Vinschen wrote: On Jun 21 13:35, Jeffrey Altman wrote: Since Cygwin Heimdal is built as Linux without any platform specific credential cache support it will be restricted to using FILE: caches as a ticket store. Microsoft Kerberos never uses FILE: based caches and native MIT and Heimdal distributions use them only when explicitly configured to. The preferred location of a krb5.conf file on Windows is %ALLUSERSPROFILE%\Kerberos\krb5.conf By reading the DOS formatted file stored at that location any configuration applied to native Kerberos library distributions will also be used by Cygwin applications. Sorry if I'm dense but what does that mean exactly for Cygwin? Assuming the Cygwin heimdal package would use that file location, would it be only able to interact correctly with other third part kerberos or heimdal packages, or would it also work with the native stuff and AD? If Cygwin shared that location it would share the configuration for native MIT and Heimdal Kerberos distributions. Microsoft's Kerberos SSP is in-kernel and does not use configuration files. All Microsoft configuration is via Group Policy and Registry manipulation. Jeffrey Altman -- 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: Heimdal 1.5.2: unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10
On 6/21/2013 3:43 AM, Corinna Vinschen wrote: Guys, whatever the problem here is, it needs to be investigated and potentially implemented by somebody who knows this kerberos/gss-api stuff. Openssh is built against these libraries and that's it from my side. If something's missing in openssh to support this correctly on Cygwin, or if the Cygwin DLL to support this authentication model, I simply don't know what it is. I appreciate any coding help. Corinna Corinna, To the best of my knowledge the Heimdal developers have not been contacted by the Cygwin Heimdal package maintainer. One of my companies, Secure Endpoints, maintains the native Windows distribution of Heimdal. http://www.secure-endpoints.com/heimdal/ Please ask the Heimdal package maintainer for Cygwin to contact me so I can understand how it is being built. Jeffrey Altman -- 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
Unable to delegate credentials from Cygwin ssh client was Re: Heimdal 1.5.2: unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10
On 6/14/2013 5:39 PM, Nogin, Aleksey wrote: I am experiencing the same error that Corinna Vinschen have reported on cygwin-apps mailing list about a year ago without any obvious resolution(*), and I was wondering whether somebody was able to resolve it since. I am running Heimdal's kinit (as came with MobaXterm 6.2) under Windows 7 to get a ticket from a Windows AD, and then ssh'ing into RHEL 5 and 6 boxes set up to use pam_krb to authenticate against the same Windows AD. gssapi-with-mic authentication succeeds, but credential delegation does not, and I see the same unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10 error(**) previously reported. This is an issue in my environment, where Kerberos-secured NFS is used to provide access to home directories. One thing I did notice is that when I ssh into an RHEL box, afterwards kinit on the client (Cygwin) side shows a ticket for the RHEL host (as expected), yet it shows that the ticket lacks the forwardable flag, which would probably explain the failure to delegate credentials. So perhaps this is a problem with the SSH client on the Cygwin end (ssh -V reports OpenSSH_6.1p1, OpenSSL 1.0.1c 10 May 2012), rather than Heimdal's? The libdefaults section in krb5.conf on Cygwin does contain forwardable = yes and in contract to how it happens on Cygwin, the Linux-Linux ssh that does delegate credentials correctly also does obtain a forwardable ticket on the client side. TIA for any help. Going back to the original posting. The Heimdal that is being used is MobaXTerm's kinit. What Heimdal is it? Is it a native Windows build? The Secure Endpoints distribution which Microsoft LSA support and MIT credential cache support? Or the Heimdal that is packaged for Cygwin? The Heimdal distribution matters because it will determine where the krb5.conf configuration file is going to be stored. If you aren't sure, use SysInternals Process Monitor to trace the kinit.exe process and see what files it accesses. When kinit is executed, is the -f parameter provided requesting a forwardable ticket granting ticket? If the ticket granting ticket (TGT) is not forwardable, then none of the derived tickets will be. When delegating credentials it is the TGT that is forwarded to the remote host, not the host/hostname@REALM service ticket which is used solely for authentication. Jeffrey Altman -- 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
Packaging Heimdal for Cygwin was Re: Heimdal 1.5.2: unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10
On 6/21/2013 10:07 AM, Corinna Vinschen wrote: To the best of my knowledge the Heimdal developers have not been contacted by the Cygwin Heimdal package maintainer. Well, if it builds... We are discussing security software that must integrate with the native environment. When MIT or Heimdal Kerberos is built for OSX it is built with specific knowledge of the OSX keychain. When XYZ Kerberos is built for Windows natively it has specific knowledge of the Microsoft LSA Kerberos cache (readonly) and provides a secure credential cache implementation into which credentials can be stored and accessed via the MIT credential cache api. The goal of Kerberos is single sign-on so if the user obtains Kerberos credentials as part of the OS logon they should be accessible to the applications that the user executes without requiring that the user enter their password again. On Linux the kernel's keyring support is often used to store Kerberos credentials because it is more secure than plain files. I suspect that functionality is not emulated by cygwin1.dll since it could not in fact be secure unless it was backed by a kernel driver. Since Cygwin Heimdal is built as Linux without any platform specific credential cache support it will be restricted to using FILE: caches as a ticket store. Microsoft Kerberos never uses FILE: based caches and native MIT and Heimdal distributions use them only when explicitly configured to. The preferred location of a krb5.conf file on Windows is %ALLUSERSPROFILE%\Kerberos\krb5.conf By reading the DOS formatted file stored at that location any configuration applied to native Kerberos library distributions will also be used by Cygwin applications. If Cygwin's /etc/krb5.conf is used the system administrator (often an end user without knowledge that Kerberos is even being used) must ensure that the two configuration files are synchronized to avoid inconsistent application behavior. I guess that cygwin1.dll could special case /etc/krb5.conf and have it shadow %ALLUSERSPROFILE%\Kerberos\krb5.conf with appropriate end-of-line translations. You can look it up in the source archive really simply: ftp://cygwin.com/pub/cygwin/release/heimdal/heimdal-1.5.2-4-src.tar.bz2 From what I gather from the heimdal.cygport file, there's nothing special in this build, except for four patch files which fix minor build problems and a signal handling bug. Of the four patches included in the tar ball all but the lib/roken/signal.c patch are specific to the Cygwin build and installation. The lib/roken/signal.c patch could be submitted upstream via a github.com pull request against https://github.com/heimdal/heimdal. Jeffrey Altman -- 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: Heimdal 1.5.2: unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10
On 6/14/2013 5:39 PM, Nogin, Aleksey wrote: debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug1: Next authentication method: gssapi-with-mic debug1: Miscellaneous failure (see text) unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10 debug1: Delegating credentials debug1: Delegating credentials debug1: Enabling compression at level 6. debug1: Authentication succeeded (gssapi-with-mic). Authenticated to XXXhostXXX ([IP.IP.IP.IP]:22). I'm not sure what the issue is here. The authentication succeeded. MechType 1.3.6.1.4.1.311.2.2.10 is Microsoft's NTLM SSP. The sshd does not support NTLM and so rejects it. The next GSS mechanism is negotiated within the gssapi-with-mic exchange. That is probably Kerberos5 and it succeeds. Jeffrey Altman -- 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: Heimdal 1.5.2: unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10
On 6/20/2013 6:31 PM, Nogin, Aleksey wrote: Jeffrey Altman wrote: debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug1: Next authentication method: gssapi-with-mic debug1: Miscellaneous failure (see text) unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10 debug1: Delegating credentials debug1: Delegating credentials debug1: Enabling compression at level 6. debug1: Authentication succeeded (gssapi-with-mic). Authenticated to XXXhostXXX ([IP.IP.IP.IP]:22). I'm not sure what the issue is here. The authentication succeeded. The issue that despite the Delegating credentials message, credentials are not being delegated. Aleksey I still do not understand what does that has to do with the subject of this message? The credentials that will be deleted are the credentials of the type that was accepted by the ssh gssapi-with-mic mechanism. At the verbosity level that you are using it does not state what that is. In any case, I am quite sure that if your ssh client states that it has delegated credentials that it has done so. You need to debug the server side to determine where the sshd environment or gssapi library has determined the credentials have been stored. For Kerberos it will need to be a credential cache. Heimdal defaults to using a non-FILE based cache but I suspect that Cygwin does not provide a non-FILE based cache implementation. Jeffrey Altman -- 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: Using native symlinks
On 5/30/2013 5:03 AM, Corinna Vinschen wrote: On the other hand, in the same situation the UAC-crippled admins's token does not contain the Create symbolic links right: $ /cygdrive/c/Windows/System32/whoami /priv PRIVILEGES INFORMATION -- Privilege NameDescription State = SeShutdownPrivilege Shut down the system Disabled SeChangeNotifyPrivilege Bypass traverse checking Enabled SeUndockPrivilege Remove computer from docking station Disabled SeIncreaseWorkingSetPrivilege Increase a process working set Disabled SeTimeZonePrivilege Change the time zone Disabled I also changed the Create symbolic links policy so that the Users group is the only group getting this right. In other words, I removed the Administrators group entirely, logged off, logged on, and the result was the same as above. This is a bug in UAC if you ask me. It seems to remove privileges from the UAC-crippled admin's token based on a fixed internal list, totally ignorant of changes in the security policy. This is a design flaw but it is working as documented. Administrators have SeCreateSymbolicLinkPrivilege by default so UAC removes it. What UAC should do in my opinion is not remove a static list of permissions but only remove those permissions that are not granted to standard users. If your organization is a user of native symlinks and you have a support agreement with Microsoft, I recommend filing a support request to have this behavior changed. Jeffrey Altman -- 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: Patch for shutdown
Frank, I would be unhappy with this proposed change. The Windows shutdown.exe uses: 'h' for hibernate 'l' for logoff 's' for shutdown and halt 'r' for shutdown and restart 'g' for shutdown and restart including registered applications 'a' for abort shutdown with the following modifiers: 'f' for force 'p' for 'no warning 'e' document the reason 'i' display GUI 'm' specify target computer 't' specify timeout 'c' specify comment 'd' shutdown reason code I believe it is very important that the Cygwin shutdown not alter the meaning of command line parameters such that they are different from the Windows native version. The various options are already too confusing to remember. Typing the right option value into wrong shell should not result in the wrong behavior if we can help it. Thank you. Jeffrey Altman On 5/20/2013 7:40 AM, Frank Fesevur wrote: Hi Corinna, Since nobody made real objections about changing the short flag for hibernate from -h to -b to make room for -h for halt [1], I created a patch to change the shutdown program. The patch was created back in March, but with all your work being done on cygwin64, your holiday and myself being very busy with life it was held back. There were no change to the shutdown CVS since then so here is that patch, including a changelog. Note that I didn't change the programs version number in this patch. I don't know if changing an existing option would require/justify to change the version from 1.9 to 2.0 instead of simply to 1.10? Regards, Frank [1] http://cygwin.com/ml/cygwin/2013-03/msg00354.html -- 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: Patch for shutdown
On 5/20/2013 9:59 AM, Fedin Pavel wrote: At the other hand, IMHO, Windows .bat scripts are never run from wihin bash, and vice versa, UNIX .sh scripts are never run from within cmd.exe... And following the same logic we would need to teach our find.exe (already mentioned on this list) to understand Windows options instead of UNIX options... Even further, in terminal case, why have Cygwin at all ? It is different from Windows command line and this is confusing... Kind regards. Unlike the 'find' command, the shutdown command can leave the machine in a state which cannot be recovered without physical access. That is the difference as I see it and it is a significant difference. Sincerely Jeffrey Altman -- 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: winln for native symlinks
On 4/4/2013 11:48 AM, Thomas Wolff wrote: It shows this error message: winln: you don't permission to create symbolic links. Run, as administrator, winln: editrights -a SeCreateSymbolicLinkPrivilege -a $YOUR_USER which should be fixed somehow like this: You don't have permission to create symbolic links. Run, as administrator, editrights -a SeCreateSymbolicLinkPrivilege -u $USER Moreover, this advice does not help. Even after having issued this command as administrator, winln -s still works as administrator only. The SeCreateSymbolicLinkPrivilege privilege is filtered by User Account Control (UAC). If your account is a member of the Administrators group, then the process needs to be run with your elevated credentials in order to make use of the SeCreateSymbolicLinkPrivilege privilege. The Administrator account always runs in an elevated state and accounts that are not members of the Administrators group do not have their security tokens filtered by UAC. Does Cygwin permit binaries to be built with manifests? If so, winln.exe could include an embedded manifest that indicates that elevated status is required. The user would then be prompted by UAC whenever the command is used. Jeffrey Altman -- 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: MIT Kfw SDK w/ Cygwin? Trying to build OpenSSH w/ GSS-API on Cygwin...
Looking at the dependencies of the Kfw DLLs I see that there is a dependency on MSVCRT.DLL. *FAQ check: MSVCRT.DLL and cygwin1.dll are mutually exclusive* But the dependency on MSVCRT.DLL by the MIT Kfw DLLs is indirect. What do you mean by indirect? The KFW DLLs are linked to MSVCRT.DLL. QUESTION: Does the MSVCRT.DLL/cygwin1.dll mutual exclusivity apply in this case? More than likely the answer is 'yes'. You can't mix C runtime environments. You would need to compile KRB5 and GSSAPI with Cygwin. If so, then I'll give up on Kfw now and try Heimdal - unfortunately that probably means giving up on Leash32. It means giving up on Leash because when you build with Cygwin you probably will not have support for the Credential Cache API. QUESTION: Does the MIT krb5 stuff build on Cygwin? Kerbnet appears to have died some time ago... SSH support including GSSAPI and linkage to MIT Kerberos is now in my K95 test builds. Jeffrey Altman * Sr.Software Designer C-Kermit 8.0 available now!!! The Kermit Project @ Columbia University includes Telnet, FTP and HTTP http://www.kermit-project.org/ secured with Kerberos, SRP, and [EMAIL PROTECTED]OpenSSL. Interfaces with OpenSSH -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: MIT Kfw SDK w/ Cygwin? Trying to build OpenSSH w/ GSS-API on Cygwin...
But the dependency on MSVCRT.DLL by the MIT Kfw DLLs is indirect. What do you mean by indirect? The KFW DLLs are linked to MSVCRT.DLL. That the resulting OpenSSH Makefile does not reference it... That is irrelevant to the problem. The problem is that the two C Run Time environments trip over each other since they both attempt to hook the same OS routines. You will also have a problem if memory allocated in one is free'd realloc'd by the other. SSH support including GSSAPI and linkage to MIT Kerberos is now in my K95 test builds. Did you build Kfw with Cygwin? I do not use Cygwin. I compile with MSVC. Jeffrey Altman * Sr.Software Designer C-Kermit 8.0 available now!!! The Kermit Project @ Columbia University includes Telnet, FTP and HTTP http://www.kermit-project.org/ secured with Kerberos, SRP, and [EMAIL PROTECTED]OpenSSL. Interfaces with OpenSSH -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: MIT Kfw SDK w/ Cygwin? Trying to build OpenSSH w/ GSS-API on Cygwin...
Danilio There are other issues that can become problems when you are using runtime environments from different vendors. Both runtime is going to try to simulate Unix style signal handling by installing Exception Handlers. When mixing debug and non-debug dlls on Windows this is not a problem because the rest of the environment is the same. This will not be true when mixing CygWin and MSVCRT.DLL. - Jeff Nico, Mixing CRTs can work. It depends on whether the code in question does not expose CRT APIs. In general, krb5 tends to be pretty good about it...or at least, I have tried to clean up some of the problems in that area. (On Windows, you might have a krb5 dll using the debug CRT while the app uses a non-debug CRT.) If the OpenSSH code is misusing the gssapi (i.e., using free directly instead of calling apropriate gssapi routines), then you'll have problems. Otherwise, I tend to think that you should generally be ok. The KfW code will use MSVCRT while the OpenSSH code uses cygwin. Since each is encapsulated in separate DLLs, they can call same-name CRT functions from different DLLs w/o any problems. Again, the problem happens if MSVCRT allocated memory (opens a file, whatever) and cygwin tries to deallocate (or use the file handle opened by MSVCRT, etc). That should not happen with well-designed APIs that do not use CRT abstractions in the API. - Danilio - Original Message - From: Nicolas Williams [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, January 03, 2002 1:24 PM Subject: MIT Kfw SDK w/ Cygwin? Trying to build OpenSSH w/ GSS-API on Cygwin... I'm trying to build OpenSSH (2.9p2, for now) with Simon Wilkinson's patches that implement the external-keyx / GSS-API extensions. Specifically I wish to use Kerberos V as the GSS mechanism. That means picking Heimdal or MIT krb5 as the Kerberos V implementation. I started with MIT krb5, specifically Kfw (Kerberos for Windows). Kfw is compiled with MSVC++ (all C). *FAQ check: it is supposedly ok to mix Cygwin with MSVC++ built (C only) DLLs* After writing the necessary autoconf checks for Kfw (library names differ) and dealing with making sure that _WIN32 is defined where the Kfw headers are included, I've gotten as far as getting a successful link of ssh.exe. But it crashes with SIGSEGV and I'm still trying to get a stack trace. Looking at the dependencies of the Kfw DLLs I see that there is a dependency on MSVCRT.DLL. *FAQ check: MSVCRT.DLL and cygwin1.dll are mutually exclusive* But the dependency on MSVCRT.DLL by the MIT Kfw DLLs is indirect. QUESTION: Does the MSVCRT.DLL/cygwin1.dll mutual exclusivity apply in this case? If so, then I'll give up on Kfw now and try Heimdal - unfortunately that probably means giving up on Leash32. QUESTION: Does the MIT krb5 stuff build on Cygwin? Kerbnet appears to have died some time ago... Thanks, Nico Jeffrey Altman * Sr.Software Designer C-Kermit 8.0 available now!!! The Kermit Project @ Columbia University includes Telnet, FTP and HTTP http://www.kermit-project.org/ secured with Kerberos, SRP, and [EMAIL PROTECTED]OpenSSL. Interfaces with OpenSSH -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: MIT Kfw SDK w/ Cygwin? Trying to build OpenSSH w/ GSS-API on Cygwin...
On Thu, Jan 03, 2002 at 03:32:01PM -0500, Jeffrey Altman wrote: Or just try to compile Krb5 with Cygwin. Has anyone done this in recent times? I have a feeling it won't work. But, hey, I could try. Still, Leash32 won't work, so I'll still need to find a GUI kinit. No, you have to compile krb5 with the appropriate modifications to use the Credential Cache API so it can use the cache stored in krbcc32s.exe Jeffrey Altman * Sr.Software Designer C-Kermit 8.0 available now!!! The Kermit Project @ Columbia University includes Telnet, FTP and HTTP http://www.kermit-project.org/ secured with Kerberos, SRP, and [EMAIL PROTECTED]OpenSSL. Interfaces with OpenSSH -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
