Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-003 (Christmas/New Year release)
On Jan 21 11:20, Corinna Vinschen wrote:
> On Jan 21 10:37, Corinna Vinschen wrote:
> > On Jan 21 02:45, Andrey Repin wrote:
> > > The setup: A Win7 machine - member of a NT4-style domain. (No AD yet.)
> > > [...]
> > I'm wondering if that's a side effect of using a NT4 domain. This isn't
> > supported in Cygwin anymore for quite some time. After all AD has
> > replaced NT4 15 years ago. All the LDAP calls to fetch the AD attributes
> > won't work in an NT4 domain, for instance.
> >
> > But even if all the calls to the DB fail, the /path scheme shouldn't be
> > affected.
>
> But it is... I just inspected the code in CYgwin fetching the extra info
> for domain accounts. Due to the way this works - a single ldap call to
> fetch all AD attributes - the evaluation only takes place after the LDAP
> call was successful. This is independent of using non-AD schemes, basically
> like this:
>
>if (is_domain_account)
> {
>[...]
>if (cldap->fetch_ad_account ())
>{
> gid = posix_offset + cldap->get_primary_gid ();
> home = cygheap->pg.get_home (cldap);
> shell = cygheap->pg.get_shell (cldap);
> gecos = cygheap->pg.get_gecos (cldap);
>}
>
> The reason here is that we have to fetch the gid value anyway, so the
> code is relying on the ldap call. The get_home(), get_shell(), get_gecos()
> methods get the full content fetched from AD and only then creates the
> pw_dir, pw_shell and pw_gecos values based on the content of nsswitch.conf.
>
> So, yes, this is a direct result of not supporting NT4 domains anymore.
FTR, Andrey and I were tackling this problem off-list, and I now added a
small, non-intrusive piece of code to allow fetching account info from
an NT4 domain.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpgAn4RpT3FK.pgp
Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-003 (Christmas/New Year release)
On Jan 21 10:37, Corinna Vinschen wrote:
> On Jan 21 02:45, Andrey Repin wrote:
> > Sorry for the holdup, I was trying to crack it by myself.
> > But I was unsuccessful, and have to reach for help.
> > Even the most striped down configuration doesn't produce visible
> > improvements.
> >
> > The setup: A Win7 machine - member of a NT4-style domain. (No AD yet.)
> > Logged in as domain user with admin rights.
> > Current profile path is C:\Users\.
> > group/passwd files are moved away.
> >
> > Contents of nsswitch.conf (the last, stripped down next to nothing attempt):
> >
> > passwd: db
> > group: db
> >
> > db_home: /%H
> > db_shell: /bin/sh
> >
> >
> > > set HOME
> > HOMEDRIVE=C:
> > HOMEPATH=\Users\anrdaemon.CCENTER
> >
> > > getent passwd %USERNAME%
> > anrdaemon:*:1051576:1049089:U-CCENTER\anrdaemon,S-1-5-21-1031481445-3291699540-3997755762-3000:/home/anrdaemon:/bin/bash
> >
> > If I understand it right, the /%H should always return usable value, so do
> > /bin/sh. But I can't get it to work.
>
> Weird, really. I just tried it again myself and it worked immediately.
>
> What I'm doing is this:
>
> - I'm *not* running cygserver.
> - Open a mintty.
> - Change the nsswitch.conf settings and save the file.
> - Start another mintty to observe the effect.
>
> If cygserver is not running, every new mintty session will see the
> latest version of the nsswitch.conf file and create the passwd/group
> entries from there.
>
> I'm wondering if that's a side effect of using a NT4 domain. This isn't
> supported in Cygwin anymore for quite some time. After all AD has
> replaced NT4 15 years ago. All the LDAP calls to fetch the AD attributes
> won't work in an NT4 domain, for instance.
>
> But even if all the calls to the DB fail, the /path scheme shouldn't be
> affected.
But it is... I just inspected the code in CYgwin fetching the extra info
for domain accounts. Due to the way this works - a single ldap call to
fetch all AD attributes - the evaluation only takes place after the LDAP
call was successful. This is independent of using non-AD schemes, basically
like this:
if (is_domain_account)
{
[...]
if (cldap->fetch_ad_account ())
{
gid = posix_offset + cldap->get_primary_gid ();
home = cygheap->pg.get_home (cldap);
shell = cygheap->pg.get_shell (cldap);
gecos = cygheap->pg.get_gecos (cldap);
}
The reason here is that we have to fetch the gid value anyway, so the
code is relying on the ldap call. The get_home(), get_shell(), get_gecos()
methods get the full content fetched from AD and only then creates the
pw_dir, pw_shell and pw_gecos values based on the content of nsswitch.conf.
So, yes, this is a direct result of not supporting NT4 domains anymore.
Sorry,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpX8Yi2tcVUB.pgp
Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-003 (Christmas/New Year release)
On Jan 21 02:45, Andrey Repin wrote: > Sorry for the holdup, I was trying to crack it by myself. > But I was unsuccessful, and have to reach for help. > Even the most striped down configuration doesn't produce visible improvements. > > The setup: A Win7 machine - member of a NT4-style domain. (No AD yet.) > Logged in as domain user with admin rights. > Current profile path is C:\Users\. > group/passwd files are moved away. > > Contents of nsswitch.conf (the last, stripped down next to nothing attempt): > > passwd: db > group: db > > db_home: /%H > db_shell: /bin/sh > > > > set HOME > HOMEDRIVE=C: > HOMEPATH=\Users\anrdaemon.CCENTER > > > getent passwd %USERNAME% > anrdaemon:*:1051576:1049089:U-CCENTER\anrdaemon,S-1-5-21-1031481445-3291699540-3997755762-3000:/home/anrdaemon:/bin/bash > > If I understand it right, the /%H should always return usable value, so do > /bin/sh. But I can't get it to work. Weird, really. I just tried it again myself and it worked immediately. What I'm doing is this: - I'm *not* running cygserver. - Open a mintty. - Change the nsswitch.conf settings and save the file. - Start another mintty to observe the effect. If cygserver is not running, every new mintty session will see the latest version of the nsswitch.conf file and create the passwd/group entries from there. I'm wondering if that's a side effect of using a NT4 domain. This isn't supported in Cygwin anymore for quite some time. After all AD has replaced NT4 15 years ago. All the LDAP calls to fetch the AD attributes won't work in an NT4 domain, for instance. But even if all the calls to the DB fail, the /path scheme shouldn't be affected. For a start, can you run `strace -o getent.trace getent passwd anrdaemon in a mintty session started *after* changing nsswitch.conf and send the getent.trace file? It might give some clue. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgptxQ413XjM_.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-003 (Christmas/New Year release)
Greetings, Corinna Vinschen! >> >> >> > I added a %H specifier to the /path schema which is substituted by >> >> >> > the >> >> >> > Windows home path in POSIX notation. So, what you should be able to >> >> >> > do >> >> >> > now is something like: >> >> >> > >> >> >> > db_home: /%H/cygwin >> >> >> >> >> >> I've used >> >> >> >> >> >>db_home: %H/cygwin >> >> >> >> > Meep! Did you read the preliminary user's guide? You really should. >> >> >> >> > >> >> > https://cygwin.com/preliminary-ug/ntsec.html#ntsec-mapping-nsswitch-passwd >> >> >> >> > The leading slash is in integral part of the "path" scheme, The above >> >> > is not recognized as valid entry at all. >> >> >> >> Speaking of validity of entries. >> >> I was toying around with my chain of VM's, and got to think about a way to >> >> debug new nsswitch.conf configurations. >> >> Is there an easy way to see, what steps are performed, and what results >> >> are >> >> returned, from schemes specified in nsswitch.conf ? >> >> > I'm not sure I understand the question. Just change the db_home >> > or whatever entry to another one and start another mintty? >> >> That would be an indirect test, that doesn't tell a whole lot if things not >> work to the expected results. >> I'm trying different configurations right now, but it seems the result always >> /home/$USER. And I'm not sure, if it is my misunderstanding, mistakes in my >> cygwin configuration, or errors in system configuration? >> It would be wonderful to have a way to directly test different schemes, even >> if only for current user. > I don't see the difference. If you don't get the desired results, > explain the setting you test and what you did. Let's discuss it. If > it's a bug, I'll fix the bug. If it's a misunderstanding on your part, > let's try to improve the documentation. Sorry for the holdup, I was trying to crack it by myself. But I was unsuccessful, and have to reach for help. Even the most striped down configuration doesn't produce visible improvements. The setup: A Win7 machine - member of a NT4-style domain. (No AD yet.) Logged in as domain user with admin rights. Current profile path is C:\Users\. group/passwd files are moved away. Contents of nsswitch.conf (the last, stripped down next to nothing attempt): passwd: db group: db db_home: /%H db_shell: /bin/sh > set HOME HOMEDRIVE=C: HOMEPATH=\Users\anrdaemon.CCENTER > getent passwd %USERNAME% anrdaemon:*:1051576:1049089:U-CCENTER\anrdaemon,S-1-5-21-1031481445-3291699540-3997755762-3000:/home/anrdaemon:/bin/bash If I understand it right, the /%H should always return usable value, so do /bin/sh. But I can't get it to work. The only other change I can think about is shortened /cygdrive prefix none / cygdrive binary,posix=0,noacl 0 0 Reverting it back doesn't make a difference. -- WBR, Andrey Repin (anrdae...@yandex.ru) 21.01.2015, <02:09> Sorry for my terrible english... -- 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)
On Jan 14 13:19, Achim Gratz wrote: > Corinna Vinschen cygwin.com> writes: > > I uploaded a snapshot and I'm going to release another test release. > > The snapshot and the test release are the same thing at the moment? Yes. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp1K_bY1ZE6J.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-003 (Christmas/New Year release)
Corinna Vinschen cygwin.com> writes: > I uploaded a snapshot and I'm going to release another test release. The snapshot and the test release are the same thing at the moment? Regards, Achim. -- 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)
On Jan 13 14:53, Corinna Vinschen wrote: > On Jan 13 13:31, Achim Gratz wrote: > > Would it be possible to give the homeDirectory preference over homeDrive? > > This order would be more useful for Cygwin since Cygwin doesn't map the > > drive when the user logs in. > > The idea of the windows scheme and the analogue %H was to reflect what > Windows does. It's hard to do the right thing here since, as usual, > there will be different takes on "right" or "wrong"... I just dropped utilizing homeDrive entirely. Cygwin uses the value of homeDirectory only now. I uploaded a snapshot and I'm going to release another test release. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpN0101msNvD.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-003 (Christmas/New Year release)
On Jan 13 14:12, cyg Simple wrote: > > From: Corinna Vinschen > > On Jan 13 09:37, cyg Simple wrote: > > user's Windows default environment at the time of a user context switch (for > > instance, logon via ssh). In that case, "leaving it as is" > > today would mean to *drop* TMP/TEMP from the environment, because that's > > what ssh does anyway. Ssh drops almost everything from the environment, > > before exec'ing the child process. And that's a good thing, because the > > environment (e.g. LOCALAPPDATA, USERPROFILE, etc) would otherwise reflect > > the settings of the user running the sshd service, not the settings of the > > user just > > logging in. > > > > Shouldn't these be removed during the startup of sshd? Then the child > process would setup the variables during the login process? That's basically what happens, except that sshd only removes the variables when starting the child process, not at its own process startup. > > Having said that, TMP/TEMP have the downside of being used by POSIX and > > Windows applications alike. Therefore these variables usually are converted > > from Windows to POSIX and vice versa on the fly. > > This is what I was referring to earlier. Yup, I just reiterated it to make sure the procedure is clear. > > However, whether it makes sense to set TMP/TEMP in a ssh logon session or a > > cron session is questionable. > > Ack. The environment tends to be empty on cron in *nix so I agree. The > logon process tends to be what sets the variables, however with Cygwin sshd > we need to logon to a new user; would remote desktop protocol provider API > help? > > http://msdn.microsoft.com/en-us/library/dd919947(v=vs.85).aspx It has no functions for that afaics. I'm using CreateEnvironmentBlock to fetch the user's default Windows env and then merge it into the environment propagated to the child process running under the user's account. I just added code to skip all crucial variables (e.g. TMP, TEMP, PATH) and uploaded a new snapshot with this change to https://cygwin.com/snapshots/ I'm also going to release another test release today. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpCmYY35QSrt.pgp Description: PGP signature
RE: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-003 (Christmas/New Year release)
> From: Corinna Vinschen > > On Jan 13 09:37, cyg Simple wrote: > > > -Original Message- > > > From: Achim Gratz > > > > > > Corinna Vinschen writes: > > > > Which means what for the Cygwin DLL? Dropping TMP/TEMP from the > > > > merged Windows env? It makes sense, I think. Of course, there > > > > will be others... > > > > My process is dependent on the fact that TMP/TEMP have in/out > > rewriting of strings from POSIX to WINDOWS so please leave it as is. > > You're missing something here. What we're talking about is a merge of the Correct, I was missing this key point. > user's Windows default environment at the time of a user context switch (for > instance, logon via ssh). In that case, "leaving it as is" > today would mean to *drop* TMP/TEMP from the environment, because that's > what ssh does anyway. Ssh drops almost everything from the environment, > before exec'ing the child process. And that's a good thing, because the > environment (e.g. LOCALAPPDATA, USERPROFILE, etc) would otherwise reflect > the settings of the user running the sshd service, not the settings of the > user just > logging in. > Shouldn't these be removed during the startup of sshd? Then the child process would setup the variables during the login process? > The new functionality we're talking about here is that the next Cygwin would > "resurrect" the Windows environment setting for the child process started by > sshd. And these settings would be the one for the user just logging in. This > would help some Windows applications which otherwise choke if these > Windows environment variables are missing. Ack. > > Having said that, TMP/TEMP have the downside of being used by POSIX and > Windows applications alike. Therefore these variables usually are converted > from Windows to POSIX and vice versa on the fly. This is what I was referring to earlier. > > However, whether it makes sense to set TMP/TEMP in a ssh logon session or a > cron session is questionable. Ack. The environment tends to be empty on cron in *nix so I agree. The logon process tends to be what sets the variables, however with Cygwin sshd we need to logon to a new user; would remote desktop protocol provider API help? http://msdn.microsoft.com/en-us/library/dd919947(v=vs.85).aspx -- cyg 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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-003 (Christmas/New Year release)
On Jan 13 09:37, cyg Simple wrote: > > -Original Message- > > From: Achim Gratz > > > > Corinna Vinschen writes: > > > Which means what for the Cygwin DLL? Dropping TMP/TEMP from the > > > merged Windows env? It makes sense, I think. Of course, there will > > > be others... > > My process is dependent on the fact that TMP/TEMP have in/out rewriting of > strings from POSIX to WINDOWS so please leave it as is. You're missing something here. What we're talking about is a merge of the user's Windows default environment at the time of a user context switch (for instance, logon via ssh). In that case, "leaving it as is" today would mean to *drop* TMP/TEMP from the environment, because that's what ssh does anyway. Ssh drops almost everything from the environment, before exec'ing the child process. And that's a good thing, because the environment (e.g. LOCALAPPDATA, USERPROFILE, etc) would otherwise reflect the settings of the user running the sshd service, not the settings of the user just logging in. The new functionality we're talking about here is that the next Cygwin would "resurrect" the Windows environment setting for the child process started by sshd. And these settings would be the one for the user just logging in. This would help some Windows applications which otherwise choke if these Windows environment variables are missing. Having said that, TMP/TEMP have the downside of being used by POSIX and Windows applications alike. Therefore these variables usually are converted from Windows to POSIX and vice versa on the fly. However, whether it makes sense to set TMP/TEMP in a ssh logon session or a cron session is questionable. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp8k3_BOQQ9m.pgp Description: PGP signature
RE: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-003 (Christmas/New Year release)
> -Original Message- > From: Achim Gratz > > Corinna Vinschen writes: > > Which means what for the Cygwin DLL? Dropping TMP/TEMP from the > > merged Windows env? It makes sense, I think. Of course, there will > > be others... My process is dependent on the fact that TMP/TEMP have in/out rewriting of strings from POSIX to WINDOWS so please leave it as is. > > Just for this question: if the Cygwin DLL always handles it no matter what, then I > think these should be dropped. If they aren't dropped, I'd say at least sshd > would need to override them. I don't want to enable PermitUserEnvironment > just to deal with these two and sshrc can't be used to change the environment. > Another idea would be to prefix WIN_ to all inherited variables so any Cygwin > program wanting to use them could pull them in as needed. > And I have a mashup of Cygwin and Windows applications. I use Cygwin as a tool for Windows applications not a replacement of the Windows applications. > As I said, I'm trying to keep Cygwin and its environment separate from Windows > as much as possible, but others have different ideas about this and would > probably want the opposite. Maybe some CYGWIN setting would allow to do > one or the other as needed (or always do it, but control the prefix), but that's of > course extra code to maintain and test. > I suppose a CYGWIN environment option could control the result with the default being the current actions. -- cyg 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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-003 (Christmas/New Year release)
Corinna Vinschen cygwin.com> writes: > Which means what for the Cygwin DLL? Dropping TMP/TEMP from the > merged Windows env? It makes sense, I think. Of course, there will > be others... Just for this question: if the Cygwin DLL always handles it no matter what, then I think these should be dropped. If they aren't dropped, I'd say at least sshd would need to override them. I don't want to enable PermitUserEnvironment just to deal with these two and sshrc can't be used to change the environment. Another idea would be to prefix WIN_ to all inherited variables so any Cygwin program wanting to use them could pull them in as needed. As I said, I'm trying to keep Cygwin and its environment separate from Windows as much as possible, but others have different ideas about this and would probably want the opposite. Maybe some CYGWIN setting would allow to do one or the other as needed (or always do it, but control the prefix), but that's of course extra code to maintain and test. Regards, Achim. -- 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)
On Jan 13 13:31, Achim Gratz wrote: > Corinna Vinschen cygwin.com> writes: > > No. How often do you change such a central setting as the db_home > > setting for all users? > > Almost never. But testing gets more involved in this way. > > > I thought it's clear how Cygwin does it. Here it is: > > > > Is homeDrive non-empty? > > If yes, convert to POSIX and use as $HOME. > > If not, is homeDirectory non-empty? > > If yes, convert to POSIX and use as $HOME. > > If no, ask the local computer for the user's profile directory. > > If it has one, convert to POSIX and use as home dir > > If not, fallback to /home/$USER. > > I'd still want something else: automount /home/ to the appropriate > directory. But, as said before, that won't work through nsswitch.conf or at > least doesn't really belong there. Not now, not yet. And this still might be automated as outlined in my other mail. It's at least worth a try, isn't it? > > ...which you can change in /etc/fstab. > > ...which has other problems for the rest of the mapped drives. I still > think the home directory should be treated separately. That's all nice and dandy, but *how*. Please look from the perspective of the Cygwin DLL. If you have a good idea how to implement this, I'm open to discuss it. But ultimately it has to be coded (SHTDI) and it has to fit into the existing code somehow. Given the existing code, what about utilizing the cygwinHome attribute, for instance? Creating a user account could be locally extended to set this attribute to some useful value. > > Right, but there's nothing Cygwin can do about it. It means, you can't > > use this db_home setting if you use ssh sessions, or you use password > > authentication (real, or via passwd -R) and mount the drive in a profile. > > Would it be possible to give the homeDirectory preference over homeDrive? > This order would be more useful for Cygwin since Cygwin doesn't map the > drive when the user logs in. The idea of the windows scheme and the analogue %H was to reflect what Windows does. It's hard to do the right thing here since, as usual, there will be different takes on "right" or "wrong"... > > Btw., what about my TMP/TEMP question? > > I think at least sshd should treat these like PATH: provide a sane default This is never the question. When I'm asking stuff like this, I'm usually talking about the Cygwin DLL, because the functionality is inside the DLL. Ssh or, fwiw, no other application have a say in the matter. In these implementaion matters, please take the look always from the lowest common denominator, the Cygwin DLL. > and ignore any existing settings. I'm not sure in which other contexts this > situation can occur, but if the Windows settings are used the path must be > converted to POSIX. I personally think that Cygwin has no business putting > files into Windows TMP/TEMP since in almost all cases the ACL will be set in > ways that either make it insecure or difficult for non-ACL-aware programs to > correctly deal with it. Which means what for the Cygwin DLL? Dropping TMP/TEMP from the merged Windows env? It makes sense, I think. Of course, there will be others... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpn1DGVvDQNq.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-003 (Christmas/New Year release)
Corinna Vinschen cygwin.com> writes: > No. How often do you change such a central setting as the db_home > setting for all users? Almost never. But testing gets more involved in this way. > I thought it's clear how Cygwin does it. Here it is: > > Is homeDrive non-empty? > If yes, convert to POSIX and use as $HOME. > If not, is homeDirectory non-empty? > If yes, convert to POSIX and use as $HOME. > If no, ask the local computer for the user's profile directory. > If it has one, convert to POSIX and use as home dir > If not, fallback to /home/$USER. I'd still want something else: automount /home/ to the appropriate directory. But, as said before, that won't work through nsswitch.conf or at least doesn't really belong there. > ...which you can change in /etc/fstab. ...which has other problems for the rest of the mapped drives. I still think the home directory should be treated separately. > Right, but there's nothing Cygwin can do about it. It means, you can't > use this db_home setting if you use ssh sessions, or you use password > authentication (real, or via passwd -R) and mount the drive in a profile. Would it be possible to give the homeDirectory preference over homeDrive? This order would be more useful for Cygwin since Cygwin doesn't map the drive when the user logs in. > Btw., what about my TMP/TEMP question? I think at least sshd should treat these like PATH: provide a sane default and ignore any existing settings. I'm not sure in which other contexts this situation can occur, but if the Windows settings are used the path must be converted to POSIX. I personally think that Cygwin has no business putting files into Windows TMP/TEMP since in almost all cases the ACL will be set in ways that either make it insecure or difficult for non-ACL-aware programs to correctly deal with it. Regards, Achim. -- 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)
On Jan 13 12:02, Achim Gratz wrote: > [using the 20150113 snapshot already] > > Corinna Vinschen cygwin.com> writes: > > The leading slash is in integral part of the "path" scheme, The above > > is not recognized as valid entry at all. > > It doesn't work differently now that I've added the slash, though. To solve > the problems with the server one must re-start both cygserver and sshd after > changing the configuration. I think it's only cygserver, though, so is > there a signal that one can send to have it invalidate the cache and re-load > the configuration like some daemons on UN*X do? No. How often do you change such a central setting as the db_home setting for all users? > In any case, the code seems to prefer the mapped drives. I don't know how > it arrives there, an AD user having a mapped home / roaming profile has the > UNC path available as the homedirectory attribute and the drive latter to > map to is the homedrive attribute. These two attributes are missing from > accounts that only have local user profiles. I thought it's clear how Cygwin does it. Here it is: Is homeDrive non-empty? If yes, convert to POSIX and use as $HOME. If not, is homeDirectory non-empty? If yes, convert to POSIX and use as $HOME. If no, ask the local computer for the user's profile directory. If it has one, convert to POSIX and use as home dir If not, fallback to /home/$USER. > This is problematic for two reasons: it brings in the standard posix=0 mount > option via the cygdrive prefix ...which you can change in /etc/fstab. > and when trying to log in via SSH onto a > server the drive mapping is not established unless that user has a desktop > session open on the server. Right, but there's nothing Cygwin can do about it. It means, you can't use this db_home setting if you use ssh sessions, or you use password authentication (real, or via passwd -R) and mount the drive in a profile. Btw., what about my TMP/TEMP question? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpoox9nTRSFs.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-003 (Christmas/New Year release)
[using the 20150113 snapshot already] Corinna Vinschen cygwin.com> writes: > The leading slash is in integral part of the "path" scheme, The above > is not recognized as valid entry at all. It doesn't work differently now that I've added the slash, though. To solve the problems with the server one must re-start both cygserver and sshd after changing the configuration. I think it's only cygserver, though, so is there a signal that one can send to have it invalidate the cache and re-load the configuration like some daemons on UN*X do? In any case, the code seems to prefer the mapped drives. I don't know how it arrives there, an AD user having a mapped home / roaming profile has the UNC path available as the homedirectory attribute and the drive latter to map to is the homedrive attribute. These two attributes are missing from accounts that only have local user profiles. This is problematic for two reasons: it brings in the standard posix=0 mount option via the cygdrive prefix and when trying to log in via SSH onto a server the drive mapping is not established unless that user has a desktop session open on the server. Regards, Achim. -- 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)
On Jan 13 06:53, Andrey Repin wrote: > Greetings, Corinna Vinschen! > > >> >> > I added a %H specifier to the /path schema which is substituted by the > >> >> > Windows home path in POSIX notation. So, what you should be able to > >> >> > do > >> >> > now is something like: > >> >> > > >> >> > db_home: /%H/cygwin > >> >> > >> >> I've used > >> >> > >> >>db_home: %H/cygwin > >> > >> > Meep! Did you read the preliminary user's guide? You really should. > >> > >> > > >> > https://cygwin.com/preliminary-ug/ntsec.html#ntsec-mapping-nsswitch-passwd > >> > >> > The leading slash is in integral part of the "path" scheme, The above > >> > is not recognized as valid entry at all. > >> > >> Speaking of validity of entries. > >> I was toying around with my chain of VM's, and got to think about a way to > >> debug new nsswitch.conf configurations. > >> Is there an easy way to see, what steps are performed, and what results are > >> returned, from schemes specified in nsswitch.conf ? > > > I'm not sure I understand the question. Just change the db_home > > or whatever entry to another one and start another mintty? > > That would be an indirect test, that doesn't tell a whole lot if things not > work to the expected results. > I'm trying different configurations right now, but it seems the result always > /home/$USER. And I'm not sure, if it is my misunderstanding, mistakes in my > cygwin configuration, or errors in system configuration? > It would be wonderful to have a way to directly test different schemes, even > if only for current user. I don't see the difference. If you don't get the desired results, explain the setting you test and what you did. Let's discuss it. If it's a bug, I'll fix the bug. If it's a misunderstanding on your part, let's try to improve the documentation. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpqQG3dDfRe6.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-003 (Christmas/New Year release)
Greetings, Corinna Vinschen! >> >> > I added a %H specifier to the /path schema which is substituted by the >> >> > Windows home path in POSIX notation. So, what you should be able to do >> >> > now is something like: >> >> > >> >> > db_home: /%H/cygwin >> >> >> >> I've used >> >> >> >>db_home: %H/cygwin >> >> > Meep! Did you read the preliminary user's guide? You really should. >> >> > >> > https://cygwin.com/preliminary-ug/ntsec.html#ntsec-mapping-nsswitch-passwd >> >> > The leading slash is in integral part of the "path" scheme, The above >> > is not recognized as valid entry at all. >> >> Speaking of validity of entries. >> I was toying around with my chain of VM's, and got to think about a way to >> debug new nsswitch.conf configurations. >> Is there an easy way to see, what steps are performed, and what results are >> returned, from schemes specified in nsswitch.conf ? > I'm not sure I understand the question. Just change the db_home > or whatever entry to another one and start another mintty? That would be an indirect test, that doesn't tell a whole lot if things not work to the expected results. I'm trying different configurations right now, but it seems the result always /home/$USER. And I'm not sure, if it is my misunderstanding, mistakes in my cygwin configuration, or errors in system configuration? It would be wonderful to have a way to directly test different schemes, even if only for current user. -- WBR, Andrey Repin (anrdae...@yandex.ru) 13.01.2015, <06:47> Sorry for my terrible english... -- 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)
On Jan 12 15:50, Andrey Repin wrote: > Greetings, Corinna Vinschen! > > >> > I added a %H specifier to the /path schema which is substituted by the > >> > Windows home path in POSIX notation. So, what you should be able to do > >> > now is something like: > >> > > >> > db_home: /%H/cygwin > >> > >> I've used > >> > >>db_home: %H/cygwin > > > Meep! Did you read the preliminary user's guide? You really should. > > > https://cygwin.com/preliminary-ug/ntsec.html#ntsec-mapping-nsswitch-passwd > > > The leading slash is in integral part of the "path" scheme, The above > > is not recognized as valid entry at all. > > Speaking of validity of entries. > I was toying around with my chain of VM's, and got to think about a way to > debug new nsswitch.conf configurations. > Is there an easy way to see, what steps are performed, and what results are > returned, from schemes specified in nsswitch.conf ? I'm not sure I understand the question. Just change the db_home or whatever entry to another one and start another mintty? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpg03Ydd25oN.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-003 (Christmas/New Year release)
Greetings, Corinna Vinschen! >> > I added a %H specifier to the /path schema which is substituted by the >> > Windows home path in POSIX notation. So, what you should be able to do >> > now is something like: >> > >> > db_home: /%H/cygwin >> >> I've used >> >>db_home: %H/cygwin > Meep! Did you read the preliminary user's guide? You really should. > https://cygwin.com/preliminary-ug/ntsec.html#ntsec-mapping-nsswitch-passwd > The leading slash is in integral part of the "path" scheme, The above > is not recognized as valid entry at all. Speaking of validity of entries. I was toying around with my chain of VM's, and got to think about a way to debug new nsswitch.conf configurations. Is there an easy way to see, what steps are performed, and what results are returned, from schemes specified in nsswitch.conf ? -- WBR, Andrey Repin (anrdae...@yandex.ru) 12.01.2015, <15:48> Sorry for my terrible english... -- 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)
On Jan 10 21:44, Achim Gratz wrote: > Corinna Vinschen writes: > > I added a %H specifier to the /path schema which is substituted by the > > Windows home path in POSIX notation. So, what you should be able to do > > now is something like: > > > > db_home: /%H/cygwin > > I've used > >db_home: %H/cygwin Meep! Did you read the preliminary user's guide? You really should. https://cygwin.com/preliminary-ug/ntsec.html#ntsec-mapping-nsswitch-passwd The leading slash is in integral part of the "path" scheme, The above is not recognized as valid entry at all. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpTHu3Xxgmvl.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-003 (Christmas/New Year release)
Corinna Vinschen writes: > I added a %H specifier to the /path schema which is substituted by the > Windows home path in POSIX notation. So, what you should be able to do > now is something like: > > db_home: /%H/cygwin I've used db_home: %H/cygwin instead. That works, sort of. The windows home is mapped to H:, therefore Cygwin decides to use /cygdrive/h/cygwin and that in turn means "posix=0" as the standard mount option. It doesn't seem to work for SSH logins onto a server however, the resulting home directory is always /home/. I can't investigate further at the moment... Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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)
On Jan 7 18:41, Corinna Vinschen wrote: > On Dec 20 19:19, Achim Gratz wrote: > > Another thing is that the Cygwin home directory is always a > > sub-directory of the windows home in our environment, so it would be > > useful if there was a placeholder for the windows home directory (%H or > > some such) for the /path override or even the schema entries to use. > > Not unreasonable but tricky. %H would be an absolute path which > collides with the current implementation in terms of the leading slash. > Hmm. I added a %H specifier to the /path schema which is substituted by the Windows home path in POSIX notation. So, what you should be able to do now is something like: db_home: /%H/cygwin If %H is preceeded by a slash, the slash gets removed since %H is already an absolute path. However, the code is not explicitely checking for nonsense, like db_home: /foo/%H/baz It will just replace that with something like /foo/cygdrive/c/Users/Willy.Brandt/baz so you end up with a broken home path. This new feature is not documented yet, and for testing I'd like to urge you to try the latest snapshot from https://cygwin.com/snapshots/ If that change works as desired, I'll add documentation and release another, hopefully one of the last, Cygwin test releases. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpaJux_SI5fC.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-003 (Christmas/New Year release)
On Jan 7 18:41, Achim Gratz wrote: > Corinna Vinschen cygwin.com> writes: > > > but that would produce some rather unwieldy and long paths for certain > > > users. So, instead of specifying the users' home directory directly I > > > would like to mount or auto-mount /home/≤user> to the actual (network) > > > home directory. > > > > Hmm. That's tricky. There's no automatism for that yet. Nsswitch.conf > > only describes how to create the passwd entry for a user. It does not > > add any mechanism to run at user context switch. And not everybody > > would like to have something like that so it needs configuration. > > > > I'm not opposed to stuff like that if it simplifies admin's job, but on > > one hand we should evaluate first if there's a way to script that, > > rather than to hardcode it into the Cygwin DLL, and on the other hand > > it's not something I'd like to add for the first cut of 1.7.34... > > I agree that this is not something that belongs into nsswitch.conf, but > since those mounts are working a bit differently on Cygwin than Linux I'd > expect that in order to make some auto-mount facility available the DLL > would need to know about it and provide at least some hooks to set them up > correctly before any process tries to use them. Adding a user mount should be scriptable. The actual home directory is the next to last entry in the user's `getent passwd' output. In a profile script, this entry can be used to generate a user bind mount from the actual dir to /home/$USER. Then, set $HOME to /home/$USER. AFAICS this doesn't require any additional DLL support. > > > > - When spawning a process under another user account, merge the user's > > > > default Windows environment into the new process' environment. > > > > > > I think this change pulls in additional environment variables with > > > windows path components when starting programs via cygserver/sshd that > > > are not a login shell (and perhaps when the user's login shell isn't > > > bash, so that profile doesn't get run), most notably PATH, TMP and TEMP. > > > If these variables are used later on by programs expecting a POSIX path > > > there, then things break. > > > > Did you try it? The idea was that these variables are converted to POSIX > > on the way in... > > They aren't, but even if they were I don't think it's the right thing to do > for some variables. Slightly edited: Ok, I see. So where exactly is the problem? Variable which already exist in the env are not overwritten ($PATH). Variables which only have a meaning for Windows apps should stay in DOS notation anyway. So what's left? TMP/TEMP/TMPDIR? If that's all, we have two choices, either convert them, or skip them. What's better? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpfQzbkXXt4n.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-003 (Christmas/New Year release)
Corinna Vinschen cygwin.com> writes: > > but that would produce some rather unwieldy and long paths for certain > > users. So, instead of specifying the users' home directory directly I > > would like to mount or auto-mount /home/≤user> to the actual (network) > > home directory. > > Hmm. That's tricky. There's no automatism for that yet. Nsswitch.conf > only describes how to create the passwd entry for a user. It does not > add any mechanism to run at user context switch. And not everybody > would like to have something like that so it needs configuration. > > I'm not opposed to stuff like that if it simplifies admin's job, but on > one hand we should evaluate first if there's a way to script that, > rather than to hardcode it into the Cygwin DLL, and on the other hand > it's not something I'd like to add for the first cut of 1.7.34... I agree that this is not something that belongs into nsswitch.conf, but since those mounts are working a bit differently on Cygwin than Linux I'd expect that in order to make some auto-mount facility available the DLL would need to know about it and provide at least some hooks to set them up correctly before any process tries to use them. > > > - When spawning a process under another user account, merge the user's > > > default Windows environment into the new process' environment. > > > > I think this change pulls in additional environment variables with > > windows path components when starting programs via cygserver/sshd that > > are not a login shell (and perhaps when the user's login shell isn't > > bash, so that profile doesn't get run), most notably PATH, TMP and TEMP. > > If these variables are used later on by programs expecting a POSIX path > > there, then things break. > > Did you try it? The idea was that these variables are converted to POSIX > on the way in... They aren't, but even if they were I don't think it's the right thing to do for some variables. Slightly edited: ~ > ssh -XA gratz@server -t env HOMEPATH=\\homes\gratz\GNU APPDATA=C:\Users\gratz\AppData\Roaming ProgramW6432=C:\Program Files TERM=xterm-256color SHELL=/bin/bash WINDIR=C:\Windows PUBLIC=C:\Users\Public CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files USERDOMAIN=EU SSH_TTY=/dev/pty0 OS=Windows_NT ALLUSERSPROFILE=C:\ProgramData USER=gratz TEMP=C:\Users\gratz\AppData\Local\Temp USERNAME=gratz ProgramFiles(x86)=C:\Program Files (x86) MAIL=/var/spool/mail//gratz PATH=/usr/bin:/bin PSModulePath=C:\Windows\system32\WindowsPowerShell\v1.0\Modules\ FP_NO_HOST_CHECK=NO PWD=/home/gratz ServerType=Standard SYSTEMDRIVE=C: CYGWIN_ROOT=D:\Freeware\Cygwin\ CYGWIN64_ROOT=D:\Freeware\Cygwin64\ USERPROFILE=C:\Users\gratz CommonProgramW6432=C:\Program Files\Common Files LOCALAPPDATA=C:\Users\gratz\AppData\Local ProgramData=C:\ProgramData SHLVL=1 HOME=/home/gratz CommonProgramFiles=C:\Program Files\Common Files COMSPEC=C:\Windows\system32\cmd.exe TMP=C:\Users\gratz\AppData\Local\Temp CYGWIN32_ROOT=D:\Freeware\Cygwin32\ LOGNAME=gratz SYSTEMROOT=C:\Windows PROGRAMFILES=C:\Program Files CYGWIN_NOWINPATH=true _=/usr/bin/env Regards, Achim. -- 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)
On Dec 20 19:19, Achim Gratz wrote: > Corinna Vinschen writes: > > The major change in this new release will be 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. > > I've just set up a box with Win8.1 Core as a build machine. I've used > the SAM desc schema and removed /etc/passwd and /etc/group and it works > great. > > > Here's one thing I still think warrants some improvement (in an AD > environment, at least): > > Previously I've always used /etc/fstab.d/ for mounting the users' > home directory onto /home/. That worked except for login via ssh > publickey since at the time ssh checks for the authorized keys that > mount isn't set up yet. So I've copied those files into a different > directory and told sshd to look there, which means I had to set up each > user manually on the server. I could now replace that mapping via AD, No, you couldn't. The cygwinFstab attribute exists in the schema, but the functionality isn't implemented yet (and won't be for a while). > but that would produce some rather unwieldy and long paths for certain > users. So, instead of specifying the users' home directory directly I > would like to mount or auto-mount /home/ to the actual (network) > home directory. Hmm. That's tricky. There's no automatism for that yet. Nsswitch.conf only describes how to create the passwd entry for a user. It does not add any mechanism to run at user context switch. And not everybody would like to have something like that so it needs configuration. I'm not opposed to stuff like that if it simplifies admin's job, but on one hand we should evaluate first if there's a way to script that, rather than to hardcode it into the Cygwin DLL, and on the other hand it's not something I'd like to add for the first cut of 1.7.34... > Another thing is that the Cygwin home directory is always a > sub-directory of the windows home in our environment, so it would be > useful if there was a placeholder for the windows home directory (%H or > some such) for the /path override or even the schema entries to use. Not unreasonable but tricky. %H would be an absolute path which collides with the current implementation in terms of the leading slash. Hmm. > > 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 > > > - When spawning a process under another user account, merge the user's > > default Windows environment into the new process' environment. > > I think this change pulls in additional environment variables with > windows path components when starting programs via cygserver/sshd that > are not a login shell (and perhaps when the user's login shell isn't > bash, so that profile doesn't get run), most notably PATH, TMP and TEMP. > If these variables are used later on by programs expecting a POSIX path > there, then things break. Did you try it? The idea was that these variables are converted to POSIX on the way in... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpex22ucqEEq.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-003 (Christmas/New Year release)
Greetings, Bryan Berns! > 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. This is where POSIX is different from Windows. What is ephemeral metadata in Windows could be quite a real file object in POSIX. -- WBR, Andrey Repin (anrdae...@yandex.ru) 28.12.2014, <06:34> Sorry for my terrible english... -- 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)
Greetings, Bryan Berns! > It would be nice if the names presented would be in what Microsoft > calls the "NameSamCompatible" format instead of DOMAIN+USERNAME If you mean "DOMAIN\USER" scheme, it would not work for obvious reasons. I.e., you can't have a file name with [back]slash. > 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. If you really curious, you can dig up the discussion on the subject starting about a year ago. I.e. a lengthy topic[1] in February of this year, when preliminary versions of this change became available. [1] mid:20140213143849.gh2...@calimero.vinschen.de -- WBR, Andrey Repin (anrdae...@yandex.ru) 28.12.2014, <03:59> Sorry for my terrible english... -- 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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-003 (Christmas/New Year release)
Corinna Vinschen writes: > The major change in this new release will be 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. I've just set up a box with Win8.1 Core as a build machine. I've used the SAM desc schema and removed /etc/passwd and /etc/group and it works great. Here's one thing I still think warrants some improvement (in an AD environment, at least): Previously I've always used /etc/fstab.d/ for mounting the users' home directory onto /home/. That worked except for login via ssh publickey since at the time ssh checks for the authorized keys that mount isn't set up yet. So I've copied those files into a different directory and told sshd to look there, which means I had to set up each user manually on the server. I could now replace that mapping via AD, but that would produce some rather unwieldy and long paths for certain users. So, instead of specifying the users' home directory directly I would like to mount or auto-mount /home/ to the actual (network) home directory. Another thing is that the Cygwin home directory is always a sub-directory of the windows home in our environment, so it would be useful if there was a placeholder for the windows home directory (%H or some such) for the /path override or even the schema entries to use. > 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 > - When spawning a process under another user account, merge the user's > default Windows environment into the new process' environment. I think this change pulls in additional environment variables with windows path components when starting programs via cygserver/sshd that are not a login shell (and perhaps when the user's login shell isn't bash, so that profile doesn't get run), most notably PATH, TMP and TEMP. If these variables are used later on by programs expecting a POSIX path there, then things break. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra -- 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] TEST RELEASE: Cygwin 1.7.34-003 (Christmas/New Year release)
Hi Cygwin friends and users,
I released another TEST version of the next upcoming Cygwin release.
The version number is 1.7.34-003.
This is the Christmas/New Year release and the last one for 2014.
Not much has changed compared to 1.7.34-002. A few minor bugfixes
and the new -k/--remove-default option to setfacl.
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 will be 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.33, 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.
- Add -k/--remove-default option to setfacl to remove all default ACL
entries from an ACL.
- Provide Cygwin documentation (PDFs and HTML) for offline usage in
/usr/share/doc/cygwin-${version}.
What changed:
-
- 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.
- The xdr functions are no longer exported for newly built executables.
Use libtirpc-devel instead.
- 32 bit only: Change default values for socket buffer size to raise
performance on 10Gb networks.
- When spawning a process under another user account, merge the user's
default Windows environment into the new process' environment.
Bug Fixes
-
- Fix the problem that ptys master side always writes single byte packages
to the slave side, and pty slaves always read VMIN byte packages from
the master side if VMIN is > 0.
Fixes: https://cygwin.com/ml/cygwin-developers/2014-11/msg0.html
- Fix a synchronization problem in signal handling when using pthreads.
Addresses: https://cygwin.com/ml/cygwin/2014-11/msg00472.html
- Fix an "invalid handle" problem when using flock(2) with a parent process
holding the lock.
Addresses: https://cygwin.com/ml/cygwin/2014-12/msg00012.html
To install 32-bit Cygwin use http://cygwin.com/setup-x86.exe
To install 64 bit Cygwin use http://cygwin.com/setup-x86_64.exe
If you're already running a 32 bit version of Cygwin on 64 bit Windows
machines, you can continue to do so. If you're planning a new install
of Cygwin on a 64 bit Windows machine, consider to use the new 64 bit
Cygwin version, unless you need certain packages not yet available in
the 64 bit release.
Have fun,
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
