Re: ssh-host-config: patch fix debug option + broken for me on Vista (non-domain)
On Jan 23 14:12, Shaddy Baddah wrote:
> On 21/01/17 09:40, szgyg wrote:
> > On 1/19/2017 7:16 PM, Corinna Vinschen wrote:
> >> The idea is that if LOGONSERVER == COMPUTERNAME your
> >> machine is not in a domain. Actually, I *never* encountered an
> >> environment
> >> in which LOGONSERVER isn't set.
> >
> > It's empty if you're using RunAs.
>
> Thank you szgyg. This is on the right track. There is a variation. I
> didn't use the RunAs command.
>
> Instead I did what I think is the almost 100% use case for running
> ssh-host-config. Which is to launch mintty by select "Run as
> administrator", elevate privilege to allow the script to add users and
> services, etc.
>
> The difference is as follows. And I test for this. I login to the
> desktop as a non-administrator. When I select "Run as administrator" I
> am prompted to enter a password for (one of) the administrator users.
>
> That mintty (and cmd prompt too obviously) do not have LOGONSERVER set.
Yes, you're both right, but it's even more weird. If I use "RunAs" from
an unprivileged user account, and the Admin account I "RunAs" as is
logged on in another terminal session at the same time, the "RunAs"
session has LOGONSERVER set. Something isn't quite right in the
backgrounds...
> Also, there is another use case which I haven't tried, but I would feel
> would result in no LOGONSERVER as well... not sure. I can try it as I
> complete this email...
>
> That is logging in to an administrator user via ssh itself.
No, that works as desired with LOGONSERVER set.
> As an aside... doesn't seem like the administrator user has the elevated
> privileges anymore. It was the case in the past. I never picked up on
> that change.
I don't understand what you mean here. The privileges are not in the
user token of the non-privileged processes in a non-elevated session,
but as soon as you use "runas", the privileges are in the user token.
> To that end, please find attached the patch to fix the LOGONSERVER
> problem. I think it should be fine for a domain environment. Because if
> you run as a domain assigned local administrator, LOGONSERVER will be
> set, even on a "Run as administrator".
>
> If you just run as a local computer administrator (whatever the
> accurate terminology is here), then you will have an empty LOGONSERVER
> and the script will run for the local user.
No, that's not right. If you run a logon session as a local admin (in
contrast to running a process via "RunAs"), LOGONSERVER will be set
to \\$COMPUTERNAME.
I'm also not quite sure if the patch is right. The comment preceeding
the check explains what we want. The idea is this (omitting the
extra test for "MicrosoftAccount"):
# This test succeeds on domain member machines only, not on DCs.
if [ "${COMPUTERNAME,,*}" != "${LOGONSERVER,,*}" ]
then
# Lowercase of USERDOMAIN
csih_PRIVILEGED_USERNAME="${COMPUTERNAME,,*}+${username}"
fi
COMPUTERNAME is the same as LOGONSERVER on non-domain machines as well
as on domain controllers. So this `if' test if the machine is a domain
member machine.
If it is, local accounts will have the Cygwin username
"$COMPUTERNAME+$username", while on non-domain machines and DCs the
Cygwin username of a local user will be "$username" only,
This is according to the rules of automatic username generation per
https://cygwin.com/cygwin-ug-net/ntsec.html,
What your patch does is to handle an empty LOGONSERVER as an indicator
that we're on a domain member machine. This doesn't look right to me.
So the basic question is this: Assuming I'm running a simple bash
script, and assuming I can't rely on the value of LOGONSERVER for the
test on being a domain member machine, how *can* I check for that?
nltest, somehow? But as far as I can see, nltest was only bundeled
with Windows 7 and later... Do we have to write another helper tool?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
signature.asc
Description: PGP signature
Re: Out of date GNU binutils, and (slightly) broken binutils 2.27
On 20/01/2017 21:33, Franchuk, Alex wrote: I've been responsible for porting a large [primarily] C++ project from Linux to Cygwin. This project generates object files at one point in the build process which exceed the object file symbol count limit (around 32k, but if I recall correctly there was actually a binutils bug limiting this further to 16k). As such, I needed an assembler and linker that supported the windows big-obj format. That was added in more recent versions of GNU binutils, however the version that is available in the Cygwin repository is discouragingly old. So the first point I want to make is to ask whether the maintainers of Cygwin binutils can be pinged to update the supported version, or to know why the last supported version is from 2014 (is there something that breaks with newer versions?). If I understood correctly, 'nm -l' suffers from a chronic slowdown on x86 (but not x86_64). This makes the cygport stage which builds debuginfo packages take forever for large projects. No-one has had the time to investigate this problem. The next step I took was to get a recent version (2.27) that does support big-obj, compile it on the system, point gcc toward that installation, and try to proceed from there. This fixed the big-obj issue, and for the most part lots of the sub-projects were working just fine. But one sub-project in particular is having an issue: the resulting binary (a dll, in this case) has a flaw in the import lookup table (.idata subsection). The import lookup table of one runtime-dependent DLL is overwriting the null entry that *ends* the previous DLL's table. So, the previous DLL tries to link with a symbol that is actually contained in the other DLL, while the other DLL still correctly points to needing that symbol as well. In other words, this makes it impossible to use the resulting DLL, because it has a dependent symbol that will never be resolved correctly. It's worth noting that lots of other things link correctly without this bug, and other DLLs within that file do not have import lookup tables that overrun each other. I thought it would be reasonable to send to this mailing list because, from what I read in the binutils source, it seemed like most of the pe/pe+ code that has been added to binutils was from Cygwin developers. I tried to find the root of the problem, but after hours of searching and debugging the linker and BFD code, I haven't found the source of the discrepancy. Please report this issue on the binutils bugzilla. Please include a test case, or at least an example of a defective PE file, and say what you think it should look like. -- 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: Pipe behavior clarification?
On 01/22/2017 04:23 PM, Eliot Moss wrote: > On 1/22/2017 3:19 PM, David Balažic wrote: >> Hi! >> >> Is this a correct pipe behavior? >> >> $ echo booo | tee >(md5sum --tag) >/dev/null >> MD5 (-) = 9c8b79bdf79ef0ee73a77b8d36d27a2d >> >> $ echo booo | tee >(md5sum --tag) | cat >/dev/null > > Here's what I think happens, even if it is a bit counter-intuitive: > >>(...) creates a subprocess, whose input comes from some kind > of pipe or socket, and tee is presented with a filename it can > use to write to that socket. > > The *output* of the >(...) subprocess is hooked up to what is > known to be the output of tee *at the time the subprocess is > created*. This happens *before* any > redirections are done. Rather, all >() and > redirections are performed in left-to-right order. But you are correct that the second >/dev/null is overwriting the stdout that was originally given by >(md5sum), and therefore tee is NOT writing to the md5sum process. > > However, in the case of the | pipe, that plumbing is set up > *before* the >(...) construct is acted on. Also correct. Mixing >() and | is usually not what you want, as you are no longer writing to the pipeline. > > Note that you could do >(md5sum --tag >whatever) if you want > to specifically control the output of md5sum. > > I am sure someone more knowledgeable will correct me if I've > missed anything important here :-) ... You got the gist of it. Order matters, and specifying more than one stdout (by any mix of >, >(), or |) is generally not what you want. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Pipe behavior clarification?
On 1/23/2017 9:32 AM, Eric Blake wrote: On 01/22/2017 04:23 PM, Eliot Moss wrote: On 1/22/2017 3:19 PM, David Balažic wrote: Hi! Is this a correct pipe behavior? $ echo booo | tee >(md5sum --tag) >/dev/null MD5 (-) = 9c8b79bdf79ef0ee73a77b8d36d27a2d $ echo booo | tee >(md5sum --tag) | cat >/dev/null Here's what I think happens, even if it is a bit counter-intuitive: (...) creates a subprocess, whose input comes from some kind of pipe or socket, and tee is presented with a filename it can use to write to that socket. The *output* of the >(...) subprocess is hooked up to what is known to be the output of tee *at the time the subprocess is created*. This happens *before* any > redirections are done. Rather, all >() and > redirections are performed in left-to-right order. But you are correct that the second >/dev/null is overwriting the stdout that was originally given by >(md5sum), and therefore tee is NOT writing to the md5sum process. However, in the case of the | pipe, that plumbing is set up *before* the >(...) construct is acted on. Also correct. Mixing >() and | is usually not what you want, as you are no longer writing to the pipeline. Note that you could do >(md5sum --tag >whatever) if you want to specifically control the output of md5sum. I am sure someone more knowledgeable will correct me if I've missed anything important here :-) ... You got the gist of it. Order matters, and specifying more than one stdout (by any mix of >, >(), or |) is generally not what you want. Dear Eric (et al.) -- I *mostly* agree with this, with the exception that >(...) is *not* an output redirection. It will present tee with the name of a file -- either a named pipe or a /dev/fdnnn file name. By experimentation I discovered that this particular replacement is not done in the same left-to-right pass as I/O redirections ... Regards - EM -- 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 with new gcc-6.3.0-1 (x86/x86_64)(Test) compiling gmp 6.1.2
Hi, I just installed the new gcc-6.3.0-1 test package (thank's for that) and tried to install optimized gmp 6.1.2 on my Skylake i7-6700K: $ uname -a CYGWIN_NT-10.0 XXX 2.6.1(0.305/5/3) 2016-12-16 11:55 x86_64 Cygwin $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/6.3.0/lto-wrapper.exe Target: x86_64-pc-cygwin Configured with: /cygdrive/i/szsz/tmpp/gcc/gcc-6.3.0-1.x86_64/src/gcc-6.3.0/configure --srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-6.3.0-1.x86_64/src/gcc-6.3.0 --prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc --docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C --build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin --without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib --enable-shared --enable-shared-libgcc --enable-static --enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit --with-dwarf2 --with-tune=generic --enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-graphite --enable-threads=posix --enable-libatomic --enable-libcilkrts --enable-libgomp --enable-libitm --enable-libquadmath --enable-libquadmath-support --enable-libssp --enable-libada --disable-symvers --with-gnu-ld --with-gnu-as --with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix --without-libintl-prefix --with-system-zlib --enable-linker-build-id --with-default-libstdcxx-abi=gcc4-compatible Thread model: posix gcc version 6.3.0 (GCC) $ tar xjvf gmp-6.1.2.tar.bz2 $ cd gmp-6.1.2 $ ABI=64 ./configure --enable-cxx results in using ABI="64" CC="gcc" CFLAGS="-O2 -pedantic -fomit-frame-pointer -m64 -mtune=skylake -march=broadwell" CPPFLAGS="" CXX="g++" CXXFLAGS="-O2 -pedantic -fomit-frame-pointer -m64 -mtune=skylake -march=broadwell" MPN_PATH=" x86_64/skylake x86_64/coreibwl x86_64/coreihwl x86_64/coreisbr x86_64/coreinhm x86_64/core2 x86_64 generic" Don't know why -march=broadwell, but -march=skylake doesn't work either. Version: GNU MP 6.1.2 Host type: skylake-unknown-cygwin ABI: 64 Install prefix:/usr/local Compiler: gcc Static libraries: yes Shared libraries: no $ make $ make check ... Making check in cxx make[3]: Entering directory '/cygdrive/d/dvd-win7-addons/contrib-cygwin/gmp/6.1.2/gmp-6.1.2/tests/cxx' make check-TESTS make[4]: Entering directory '/cygdrive/d/dvd-win7-addons/contrib-cygwin/gmp/6.1.2/gmp-6.1.2/tests/cxx' make[5]: Entering directory '/cygdrive/d/dvd-win7-addons/contrib-cygwin/gmp/6.1.2/gmp-6.1.2/tests/cxx' PASS: t-binary.exe PASS: t-cast.exe PASS: t-cxx11.exe PASS: t-headers.exe ../../test-driver: line 107: 1276 Segmentation fault (core dumped) "$@" > $log_file 2>&1 FAIL: t-iostream.exe (exit status: 139) ../../test-driver: line 107: 11664 Segmentation fault (core dumped) "$@" > $log_file 2>&1 FAIL: t-istream.exe(exit status: 139) ../../test-driver: line 107: 9428 Segmentation fault (core dumped) "$@" > $log_file 2>&1 FAIL: t-locale.exe (exit status: 139) ... Testsuite summary for GNU MP 6.1.2 # TOTAL: 20 # PASS: 17 # SKIP: 0 # XFAIL: 0 # FAIL: 3 # XPASS: 0 # ERROR: 0 I suppose it has something to do with the new compiler, since - gcc-5.4.0 worked fine (okay, with broadwell optimizations) - the just arrived gmp-6.1.2-1 package seemed to compile (with gcc-5.4.0) - everything works fine when I compile my own gcc 6.3.0 via .bashrc: export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH export LIBRARY_PATH=/usr/local/lib export CPATH=/usr/local/include:$CPATH export PATH=/usr/local/bin:$PATH tar xjvf gcc-6.3.0.tar.bz2 mkdir compile cd compile ../gcc-6.3.0/configure --enable-languages=c,c++,objc,fortran --with-default-libstdcxx-abi=gcc4-compatible make -j 4 make install and then install gmp as above Is there something wrong with gcc-6.3.0-1? Attached is a slightly redacted output of cygcheck -s -v -r > cygcheck.out. Regards, Torsten cygcheck.out.bz2 Description: Binary data -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Pipe behavior clarification?
On 23 January 2017 at 15:32, Eric Blake wrote: > On 01/22/2017 04:23 PM, Eliot Moss wrote: >> On 1/22/2017 3:19 PM, David Balažic wrote: >>> Hi! >>> >>> Is this a correct pipe behavior? >>> >>> $ echo booo | tee >(md5sum --tag) >/dev/null >>> MD5 (-) = 9c8b79bdf79ef0ee73a77b8d36d27a2d >>> >>> $ echo booo | tee >(md5sum --tag) | cat >/dev/null >> >> Here's what I think happens, even if it is a bit counter-intuitive: >> >>>(...) creates a subprocess, whose input comes from some kind >> of pipe or socket, and tee is presented with a filename it can >> use to write to that socket. >> >> The *output* of the >(...) subprocess is hooked up to what is >> known to be the output of tee *at the time the subprocess is >> created*. This happens *before* any > redirections are done. > > Rather, all >() and > redirections are performed in left-to-right order. > But you are correct that the second >/dev/null is overwriting the > stdout that was originally given by >(md5sum), and therefore tee is NOT > writing to the md5sum process. The last part is incorrect. tee is always writing to the md5sum process. It can be verified by redirecting the md5sum output to a file, like >(md5sum > file1), or redirecting the final output to a file instead of /dev/null. In both cases the (correct) md5 hash will be there. Regards, David PS: I verified on SLES 11 that the behavior is the same as in cygwin, so the thread is "technically closed". -- 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: ssh-host-config: patch fix debug option + broken for me on Vista (non-domain)
Corinna Vinschen writes: > COMPUTERNAME is the same as LOGONSERVER on non-domain machines as well > as on domain controllers. So this `if' test if the machine is a domain > member machine. I can supply another cornercase where LOGONSERVER is not set: if you run an sshd under the (only) user that can log in, that ssh session has no LOGONSERVER set. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs -- 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
[ANNOUNCEMENT] Updated: bash-4.4.11-2
A new release of bash, 4.4.11-2, has been uploaded and will soon reach a mirror near you. This release replaces 4.4.5-1 as current, and works with either the current libreadline7-7.0.1-1 or experimental libreadline7-7.0.1-2. NEWS: = This build incorporates 6 new official upstream patches; no downstream Cygwin changes have been made from the previous build. There are a few things you should be aware of before using this version: 1. When using binary mounts, cygwin programs try to emulate Linux. Bash on Linux does not understand \r\n line endings, but interprets the \r literally, which leads to syntax errors or odd variable assignments. Therefore, you will get the same behavior on Cygwin binary mounts by default. 2. d2u is your friend. You can use it to convert any problematic script into binary line endings. 3. Cygwin text mounts automatically work with either line ending style, because the \r is stripped before bash reads the file. If you absolutely must use files with \r\n line endings, consider mounting the directory where those files live as a text mount. However, text mounts are not as well tested or supported on the cygwin mailing list, so you may encounter other problems with other cygwin tools in those directories. 4. This version of bash has a cygwin-specific set option, named "igncr", to force bash to ignore \r, independently of cygwin's mount style. As of bash-3.2.3-5, it controls regular scripts, command substitution, and sourced files; bash-4.3.43-5 adds the read builtin to the list. I hope to convince the upstream bash maintainer to accept this patch into a future bash release even on Linux, rather than keeping it a cygwin-specific patch, but only time will tell. There are several ways to activate this option: 4a. For a single affected script, add this line just after the she-bang: (set -o igncr) 2>/dev/null && set -o igncr; # comment is needed 4b. For a single script, invoke bash explicitly with the option, as in 'bash -o igncr ./myscript' rather than the simpler './myscript'. 4c. To affect all scripts, export the environment variable BASH_ENV, pointing to a file that sets the shell option as desired. Bash will source this file on startup for every script. 4d. Added in the bash-3.2-2 release: export the environment variable SHELLOPTS with igncr included in it. It is read-only from within bash, but you can set it before invoking bash; once in bash, it auto-tracks the current state of 'set -o igncr'. If exported, then all bash child processes inherit the same option settings; with the exception added in 3.2.9-11 that certain interactive options are not inherited in non-interactive use. 4e. bash-4.1.9-1 dropped support for 'shopt -s igncr'; it did not make sense to support the option through both set and shopt, and SHELLOPTS proved to be more powerful. 5. You can also experiment with the IFS variable for controlling how bash will treat \r during variable expansion. 6. There are varying levels of speed at which bash operates. The fastest is on a binary mount with igncr disabled (the default behavior). Next would be text mounts with igncr disabled and no \r in the underlying file. Next would be binary mounts with igncr enabled. And the slowest that bash will operate is on text mounts with igncr enabled. 7. As an additional cygwin extension, this version of bash includes completion_strip_exe - using 'shopt -s completion_strip_exe' makes completion strip .exe suffixes 8. This version of bash is immune to ShellShock (CVE-2014-6271 and friends) because it exports functions via 'BASH_FUNC_foo%%=' rather than 'foo=' environment variables. However, doing this has exposed weaknesses in some other utilities like 'ksh' or 'at' that fail to scrub their environment to exclude what is not a valid name for them. 9. If you don't like how bash behaves, then propose a patch, rather than proposing idle ideas. This turn of events has already been talked to death on the mailing lists by people with many ideas, but few patches. Thanks to Dan Colascione for providing the EXECIGNORE (now officially upstream) and completion_strip_exe patches. Remember, you must not have any bash or /bin/sh instances running when you upgrade the bash package. This release requires cygwin-2.6.1-1 or later. See also the upstream documentation in /usr/share/doc/bash/. DESCRIPTION: Bash is an sh-compatible shell that incorporates useful features from the Korn shell (ksh) and C shell (csh). It is intended to conform to the IEEE POSIX P1003.2/ISO 9945.2 Shell and Tools standard. It offers functional improvements over sh for both programming and interactive use. In addition, most sh scripts can be run by Bash without modification. As of the bash 3.0 series, cygwin /bin/sh defaults to bash, not ash, similar to some Linux distributions (although /bin/sh may swap to dash at some future time). UPDATE: === To update your installation, click on the "Install Cygwin now" link on the http://cygwin.com/ web
Re: ssh-host-config: patch fix debug option + broken for me on Vista (non-domain)
On 01/23/2017 02:50 PM, Achim Gratz wrote: Corinna Vinschen writes: COMPUTERNAME is the same as LOGONSERVER on non-domain machines as well as on domain controllers. So this `if' test if the machine is a domain member machine. I can supply another cornercase where LOGONSERVER is not set: if you run an sshd under the (only) user that can log in, that ssh session has no LOGONSERVER set. Regards, Achim. FWIW On my W10 machine (CYGWIN_NT-10.0 rwells-x220 2.6.0(0.304/5/3) 2016-08-31 14:32 x86_64 Cygwin) they are both defined and different. AFAICS I am the only configured user. -- Roger Wells, P.E. leidos 221 Third St Newport, RI 02840 401-847-4210 (voice) 401-849-1585 (fax) roger.k.we...@leidos.com -- 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
fingerprint for the 64 bit installer
Hi - I want to verify the fingerprint on your site for the installer. I downloaded the key and imported it. then i used gpg --verify file1 file1.sig and I have no way to check the signature on those 2 files because the fingerprint is not listed on the cygwin site! Please advise... thx. - J. McNamara (3rdshiftcoder) -- Sent with my mu4e -- 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
solved-no fingerprint on site
Hi- I found a solution. I can use gpg --list-keys based on the sig file that I used to import the keys. thx. - jim -- Sent with my mu4e -- 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
fingerprint clarification
Hi- I meant to say I imported the key and can gpg --verify the setup program and signature with the imported keys e.g. keys.asc. I can use gpg --list-keys to see the keys too. sorry I rushed in my last post. I had trouble with sending a message. gmail uses html. I had to switch pcs and send from mu4e mail client. thx. so much- sorry to bother you all, J. McNamara -- Sent with my mu4e -- 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
