* Re: odd behavior of symlinks on Win XP SP2
[not found] ` <corinna-cygwin@cygwin.com>
@ 2005-01-15 23:18 ` Jeff.Hodges
2005-01-16 15:15 ` Corinna Vinschen
2005-01-17 17:01 ` Jeff.Hodges
` (17 subsequent siblings)
18 siblings, 1 reply; 77+ messages in thread
From: Jeff.Hodges @ 2005-01-15 23:18 UTC (permalink / raw)
To: cygwin
Thanks for looking at this Igor. Glad to know it isn't just me.
pechtcha@cs.nyu.edu said:
> And, lo and behold, on a plain WinXP SP1 (note, no SP2) I get the
> same behavior.
aha. innaresting. Well, I installed vanilla XP and then copied over a buncha
directories from my old Win2k box, including \cygwin, and didn't play with it
much before I upgraded to SP2. So I didn't really note anything while it was
pre-SP2.
> Perhaps an update to Cygwin's symlink() implementation is in order?
that's what I'm thinking.
corinna-cygwin@cygwin.com said:
> 2001. The shortcuts have been added to Cygwin in 2001.
ah, ok. I guess I didn't really start playing/using Cygwin in somewhat ernest
until around then anyway.
corinna-cygwin@cygwin.com said:
> And it doesn't really fail. The shortcut is still a shortcut in
> Windows Explorer.
Well, I claim that it *does* "really fail" because they (cygwin-created
shortcut/symlinks) no longer -- on XP as compared to Win2k -- behave as they
did. One uses file open/save dialogs very often when using windoze and on XP
the cygwin-created shortcut/symlinks no longer behave as-documented (or
as-in-an-explorer-window). So they don't "fail in all use cases", rather they
"fail in some often-exercised use cases".
Seems to me we ought to see if we can't update the symlink() impl such that
this is addressed. I'm betting there's some new attributes or whatever (as
Igor notes) that've been added to symlinks in XP and if we can figure out what
that is, and figure out what the minimum is we need to change in our
cygwin-created .lnk files, we can perhaps (likely?) fix this without adversely
affecting performance. Maybe there's some new system call on XP that we can
use to create these buggers (if we're lucky)? After all, AFAIK, all cygwin
cares about is the cygwin path being in the .lnk file's "comment"
attribute/field, yes?
thanks again for looking into this,
JeffH
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: odd behavior of symlinks on Win XP SP2
2005-01-15 23:18 ` odd behavior of symlinks on Win XP SP2 Jeff.Hodges
@ 2005-01-16 15:15 ` Corinna Vinschen
0 siblings, 0 replies; 77+ messages in thread
From: Corinna Vinschen @ 2005-01-16 15:15 UTC (permalink / raw)
To: cygwin
On Jan 15 08:17, Jeff.Hodges@KingsMountain.com wrote:
> Seems to me we ought to see if we can't update the symlink() impl such that
> this is addressed. I'm betting there's some new attributes or whatever (as
> Igor notes) that've been added to symlinks in XP and if we can figure out what
> that is, and figure out what the minimum is we need to change in our
> cygwin-created .lnk files, we can perhaps (likely?) fix this without adversely
> affecting performance. Maybe there's some new system call on XP that we can
> use to create these buggers (if we're lucky)? After all, AFAIK, all cygwin
> cares about is the cygwin path being in the .lnk file's "comment"
> attribute/field, yes?
I'm glad that you're talking about "us" as a group. Anybody interested
in tracking that down?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader mailto:cygwin@cygwin.com
Red Hat, Inc.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: odd behavior of symlinks on Win XP SP2
[not found] ` <corinna-cygwin@cygwin.com>
2005-01-15 23:18 ` odd behavior of symlinks on Win XP SP2 Jeff.Hodges
@ 2005-01-17 17:01 ` Jeff.Hodges
2005-01-17 17:32 ` Christopher Faylor
2005-01-31 21:15 ` odd behavior of symlinks on Win XP Jeff.Hodges
` (16 subsequent siblings)
18 siblings, 1 reply; 77+ messages in thread
From: Jeff.Hodges @ 2005-01-17 17:01 UTC (permalink / raw)
To: cygwin
> I'm glad that you're talking about "us" as a group. Anybody interested
> in tracking that down?
I'm not in a position to hack code on this unfortunately, but I can offer to
test.
I suspect it's important in the longer term to track this down because they
(MSFT) ~could~ make further changes down the road that break cygwin-created
symlinks altogether (from the windoze perspective), which'd more than just
"annoying".
JeffH
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: odd behavior of symlinks on Win XP SP2
2005-01-17 17:01 ` Jeff.Hodges
@ 2005-01-17 17:32 ` Christopher Faylor
2005-01-17 22:08 ` Sven Köhler
0 siblings, 1 reply; 77+ messages in thread
From: Christopher Faylor @ 2005-01-17 17:32 UTC (permalink / raw)
To: cygwin
On Mon, Jan 17, 2005 at 08:25:26AM -0800, Jeff.Hodges@KingsMountain.com wrote:
>> I'm glad that you're talking about "us" as a group. Anybody interested
>> in tracking that down?
>
>I'm not in a position to hack code on this unfortunately, but I can offer to
>test.
>
>I suspect it's important in the longer term to track this down because they
>(MSFT) ~could~ make further changes down the road that break cygwin-created
>symlinks altogether (from the windoze perspective), which'd more than just
>"annoying".
No, Microsoft is not going to break things so that cygwin's symlinks no
longer operate. Cygwin understands its own version of symlinks very well.
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: odd behavior of symlinks on Win XP SP2
2005-01-17 17:32 ` Christopher Faylor
@ 2005-01-17 22:08 ` Sven Köhler
2005-01-17 23:11 ` Christopher Faylor
0 siblings, 1 reply; 77+ messages in thread
From: Sven Köhler @ 2005-01-17 22:08 UTC (permalink / raw)
To: cygwin
>>I suspect it's important in the longer term to track this down because they
>>(MSFT) ~could~ make further changes down the road that break cygwin-created
>>symlinks altogether (from the windoze perspective), which'd more than just
>>"annoying".
>
> No, Microsoft is not going to break things so that cygwin's symlinks no
> longer operate. Cygwin understands its own version of symlinks very well.
This comment is ridiculous. He clearly complained about MS-Software that
cannot handle cygwin-created links, and you're talking about cygwin
understand its own symlinks - well, think about it again.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: odd behavior of symlinks on Win XP SP2
2005-01-17 22:08 ` Sven Köhler
@ 2005-01-17 23:11 ` Christopher Faylor
0 siblings, 0 replies; 77+ messages in thread
From: Christopher Faylor @ 2005-01-17 23:11 UTC (permalink / raw)
To: cygwin
On Mon, Jan 17, 2005 at 10:33:47PM +0100, Sven K?hler wrote:
>>>I suspect it's important in the longer term to track this down because
>>>they (MSFT) ~could~ make further changes down the road that break
>>>cygwin-created symlinks altogether (from the windoze perspective),
>>>which'd more than just "annoying".
>>
>>No, Microsoft is not going to break things so that cygwin's symlinks no
>>longer operate. Cygwin understands its own version of symlinks very well.
>
>This comment is ridiculous. He clearly complained about MS-Software that
>cannot handle cygwin-created links, and you're talking about cygwin
>understand its own symlinks - well, think about it again.
Apologies. I took the word "altogether" to mean "completely" but
obviously missed the meaning implied by "from the windoze perspective".
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: odd behavior of symlinks on Win XP
[not found] ` <corinna-cygwin@cygwin.com>
2005-01-15 23:18 ` odd behavior of symlinks on Win XP SP2 Jeff.Hodges
2005-01-17 17:01 ` Jeff.Hodges
@ 2005-01-31 21:15 ` Jeff.Hodges
2005-02-01 19:43 ` Jeff.Hodges
` (15 subsequent siblings)
18 siblings, 0 replies; 77+ messages in thread
From: Jeff.Hodges @ 2005-01-31 21:15 UTC (permalink / raw)
To: cygwin; +Cc: Jan Hlavacek
corinna-cygwin@cygwin.com said:
> There's a patch in current Cygwin CVS which should solve the icon
> problem.
Super. Tho, will fixing "the icon problem" also fix the behavior dichotomy
between Explorer and Open/Save dialogs (which I noted in my original posting
in this thread)?
> If you want to use a shortcut in Cygwin and in native Windows, create
> it in Cygwin and don't touch it.
Indeed, and that appears to work fine on Win2k but not XP (yet).
JeffH
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: odd behavior of symlinks on Win XP
[not found] ` <corinna-cygwin@cygwin.com>
` (2 preceding siblings ...)
2005-01-31 21:15 ` odd behavior of symlinks on Win XP Jeff.Hodges
@ 2005-02-01 19:43 ` Jeff.Hodges
2005-02-01 20:48 ` Christopher Faylor
2008-01-22 9:08 ` hard link error on Vista with recent snapshots Herb Maeder
` (14 subsequent siblings)
18 siblings, 1 reply; 77+ messages in thread
From: Jeff.Hodges @ 2005-02-01 19:43 UTC (permalink / raw)
To: cygwin
> On Jan 31 12:25, Jeff.Hodges@KingsMountain.com wrote:
> > corinna-cygwin@cygwin.com said:
> > > There's a patch in current Cygwin CVS which should solve the icon
> > > problem.
> >
> > Super. Tho, will fixing "the icon problem" also fix the behavior dichotomy
> > between Explorer and Open/Save dialogs (which I noted in my original
> > posting in this thread)?
>
> Yes.
Great, thanks :)
When might this find it's way into the setup.exe install?
thanks again,
JeffH
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: hard link error on Vista with recent snapshots
[not found] ` <corinna-cygwin@cygwin.com>
` (3 preceding siblings ...)
2005-02-01 19:43 ` Jeff.Hodges
@ 2008-01-22 9:08 ` Herb Maeder
2008-10-10 0:36 ` invalid login gid in /etc/passwd does not show group name as 'mkgroup' Herb Maeder
` (13 subsequent siblings)
18 siblings, 0 replies; 77+ messages in thread
From: Herb Maeder @ 2008-01-22 9:08 UTC (permalink / raw)
To: cygwin
On Jan 21 16:23, Corinna Vinschen wrote:
> On Jan 21 15:53, Corinna Vinschen wrote:
> > On Jan 19 07:30, Herb Maeder wrote:
> > > I'm seeing a error when creating hard links under Vista using the
> > > cygwin1.dll snapshots starting at cygwin1-20070802.dll (through at
> > > least cygwin1-20080112.dll).
> > >
> > > To reproduce:
> > > * stop/exit all cygwin processes
> > > * replace bin/cygwin1.dll with one of the snapshot dlls above
> > > * fire up bash and run the following commands:
> > > % rm -rf foo bar
> > > % touch foo
> > > % ln foo bar
> > > ln: creating hard link `bar' => `foo': Permission denied
> >
> > Thanks for the report. I fixed this in CVS. As it turned out, you
> > can't open a file with access flags set to 0. ZwOpenFile requires at
> ^^^^^
> ...in Vista/Longhorn.
>
> > least READ_CONTROL access.
> ^^^^
> ...in Vista/Longhorn. 0 works fine in earlier
> Windows versions.
Excellent! Thank you very much for the explanation and the quick fix.
Herb.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: invalid login gid in /etc/passwd does not show group name as 'mkgroup'
[not found] ` <corinna-cygwin@cygwin.com>
` (4 preceding siblings ...)
2008-01-22 9:08 ` hard link error on Vista with recent snapshots Herb Maeder
@ 2008-10-10 0:36 ` Herb Maeder
2008-10-11 7:22 ` Herb Maeder
` (12 subsequent siblings)
18 siblings, 0 replies; 77+ messages in thread
From: Herb Maeder @ 2008-10-10 0:36 UTC (permalink / raw)
To: cygwin
On 09 Oct 2008 13:05:36 +0200, Corinna Vinschen wrote:
> On Oct 7 11:22, Herb Maeder wrote:
> > The "Special values of user and group ids" section of the Cygwin User's
> > Guide (http://cygwin.com/1.7/cygwin-ug-net.html#ntsec-ids) states:
> >
> > Also, since Cygwin release 1.3.20, if the current user is present in
> > /etc/passwd, but that user's login group is not present in /etc/group,
> > the group name will be shown as 'mkgroup', again indicating the
> > appropriate command.
> >
> > I don't see that this holds true, at least for the case of a Domain User.
> > In fact, I see that an invalid login group id will be shown as a group
> > name of 'Domain Users' even though there is no such gid listed in
> > /etc/group. This can be confusing since things appear to work normally on
> > the surface, but some commands may fail in some not-so-obvious ways as a
> > result of the invalid login gid.
> >
> > . . .
> >
> > I'm not sure if this is specific to Domain Users or not. Also I don't
> > know if there is some valid reason for this behavior.
>
> It's not specific to "Domain Users" and there's no *valid* reason for
> this. The whole idea (which is a couple of years old, from 2002
> actually) is that Cygwin tries to have valid passwd and group entries in
> memory for *at least* the current user. So, the situation from Cygwin's
> point of view develops along these lines:
>
> First, Cygwin checks the user token and finds the user's primary
> group SID.
>
> Next it checks /etc/passwd and finds that the pgid is 898.
>
> There's no /etc/group entry for the primary gid of the current user?
> Ok, let's create one so that this gid makes sense.
>
> Grab the SID. Check if there's a group entry corresponding to that
> SID. Gotcha. It's the entry with gid 10513 (which is ignored) and
> the name "Domain Users".
>
> Ok, so let's add a group entry in memory like this:
>
> Domain Users:S-1-5-21-1936786716-3317986166-2952453263-513:898:
>
> Bingo. We now have two entries for Domain Users, one with gid 898
> and one with 10513.
Thanks for the explanation. The behavior makes sense to me now.
But I think that means that some of the information in the "Special values
of user and group ids" section of the Cygwin User's Guide is out of date.
Would it be appropriate to include some of the information from your
description above in that section?
> It's well meant since you now see the real name of your primary group.
> And, in theory, nothing bad should happen since the underlying SID is
> correct. But the outcome is somewhat puzzeling, whatever Cygwin does.
> For instance, the gid of a file depends on the numbers. If the pgid is
> smaller than the real gid, files are owned by the faked pgid and vice
> versa. Either way, id will show you two group entries which have the
> same meaning, even if the names would differ (Domain User/mkgroup).
Also, it should be noted that some applications may behave unexpectedly
because of the situation ("rsync --link-dest", for one). But I think your
solution below will give the user fair warning that something may not be
quite right.
On 09 Oct 2008 14:14:54 +0200, Corinna Vinschen wrote:
> I changed the code to create a fake group name which should explain
> what's going on. Or maybe confuse the crap out of you. But at least
> it's something we can use here on the list:
>
> $ ls -l foobar
> -rw-r--r-- 1 herb passwd/group_GID_clash(898/10513) 0 Oct 7 10:27 foobar
Cool! It ain't pretty, but it will certainly give the user a fighting
chance to detect the issue before it causes obscure problems later on.
Plus since it will show up in "cygcheck -s" output, it will be useful for
folks on this list, as you say.
Would it be possible to add a case for this group name in the /etc/profile
"id -ng" case statement so that the user will be notified and have some
idea of what it means and what to do about it?
The "passwd/group_GID_clash" group name probably also deserves a mention
in the Cygwin User's Guide.
Thank you for investigating this issue and implementing a reasonable
solution.
Herb.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: invalid login gid in /etc/passwd does not show group name as 'mkgroup'
[not found] ` <corinna-cygwin@cygwin.com>
` (5 preceding siblings ...)
2008-10-10 0:36 ` invalid login gid in /etc/passwd does not show group name as 'mkgroup' Herb Maeder
@ 2008-10-11 7:22 ` Herb Maeder
2008-10-15 5:43 ` Herb Maeder
` (11 subsequent siblings)
18 siblings, 0 replies; 77+ messages in thread
From: Herb Maeder @ 2008-10-11 7:22 UTC (permalink / raw)
To: cygwin
On 10 Oct 2008 11:35:08 +0200, Corinna Vinschen wrote:
> > But I think that means that some of the information in the "Special values
> > of user and group ids" section of the Cygwin User's Guide is out of date.
> >
> > Would it be appropriate to include some of the information from your
> > description above in that section?
>
> I don't think that these internals should be mentioned in the user's guide.
The point is moot since that section is due for a rewrite anyway. I was
just trying to say that "some" of the information you provided was more
relevant (and certainly more correct) than what's there now. In any
case, I'm sure that your sense of what level of detail is appropriate
for the user is quite correct.
> > Would it be possible to add a case for this group name in the /etc/profile
> > "id -ng" case statement so that the user will be notified and have some
> > idea of what it means and what to do about it?
>
> id is a generic tool from coreutils. I for one wouldn't think it
> prudent to add special Cygwin code just to warn the user of some
> system specific corner case.
Perhaps my intention was not clearly stated. I believe that a case
statement was added to /etc/profile long ago, specifically to warn users
that the group name was set to one of the cygwin special cases. I'm
referring to this statement in the cygwin default /etc/profile:
# Check to see if mkpasswd/mkgroup needs to be run try and cut down the emails
# about this on the lists!
# If this message keeps appearing and you are sure it's a mistake (ie, don't
# email about it!), comment out the test below.
case `id -ng` in
mkpasswd )
echo "Your group is currently \"mkpasswd\". This indicates that"
echo "the /etc/passwd (and possibly /etc/group) files should be rebuilt."
echo "See the man pages for mkpasswd and mkgroup then, for example, run"
echo "mkpasswd -l [-d] > /etc/passwd"
echo "mkgroup -l [-d] > /etc/group"
echo "Note that the -d switch is necessary for domain users."
;;
. . .
If that case statement is no longer prudent, perhaps it should be removed.
But if it ends up sticking around, then it probably makes sense to account
for the additional special case that was just introduced:
passwd/group_GID_clash* )
echo "Your group is currently \"passwd/group_GID_clash\". This indicates"
echo "blah, blah, blah..."
;;
> > The "passwd/group_GID_clash" group name probably also deserves a mention
> > in the Cygwin User's Guide.
>
> That's right, but this part of the ntsec documentation is waiting
> patiently for an update for a long time anyway. I just had always
> more important stuff to do (looking tv, sleeping, ...)
I can certainly appreciate that! I knew that the 1.7 version of the
user's guide had undergone revision, but I didn't realize that this
section was still on the todo list. I'm sure it will all sort itself
out nicely in the update.
Thanks again,
Herb.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: invalid login gid in /etc/passwd does not show group name as 'mkgroup'
[not found] ` <corinna-cygwin@cygwin.com>
` (6 preceding siblings ...)
2008-10-11 7:22 ` Herb Maeder
@ 2008-10-15 5:43 ` Herb Maeder
2008-10-23 19:18 ` cygwin bash crashes on Win Serv 2008 Freddy Jensen
` (10 subsequent siblings)
18 siblings, 0 replies; 77+ messages in thread
From: Herb Maeder @ 2008-10-15 5:43 UTC (permalink / raw)
To: cygwin
On 13 Oct 2008 17:54:36 +0200, Corinna Vinschen wrote:
> > But if it ends up sticking around, then it probably makes sense to account
> > for the additional special case that was just introduced:
> >
> > passwd/group_GID_clash* )
> > echo "Your group is currently \"passwd/group_GID_clash\". This indicat
es"
> > echo "blah, blah, blah..."
> > ;;
> >
> > > > The "passwd/group_GID_clash" group name probably also deserves a mentio
n
> > > > in the Cygwin User's Guide.
>
> Yes, you're right, adding a case for passwd/group_GID_clash would be
> nice. http://cygwin.com/acronyms/#SHTDI I'm sure the maintainer
> of the base-passwd package would appreciate a patch.
Sure, I'd be happy to do that.
But before submitting a patch, I'd like to make sure I know what I'm talking
about so I can submit a proper patch for the whole case statement. Can you
confirm that the following are correct?
1) It is no longer possible to end up with the "mkgroup_l_d" group name.
If I understand it correctly, this possibility went away in version
1.30 of mkgroup.c. If so, that case should be removed from the
/etc/profile case statement.
2) The group name will be 'mkpasswd' if the current user's effective gid
is not in /etc/group and the effective uid is not in /etc/passwd.
3) The group name will be 'passwd/group_GID_clash(%ld/%ld)' if the
current user's effective gid is not in /etc/group, the effective
uid is in /etc/passwd, and the gid associated with the user's SID is
in /etc/group.
4) The group name will be 'mkgroup' if the current user's effective gid
is not in /etc/group, the effective uid is in /etc/passwd, and the
gid associated with the user's SID is not in /etc/group.
If that's all correct, perhaps this chunk of pseudo-code says it more
succinctly:
if (current users effective gid not in /etc/group) {
if (current users effective uid not in /etc/passwd) {
group_name="mkpasswd";
} else if (current users SID group is in /etc/group) {
group_name="passwd/group_GID_clash(egid/pgsid)"
} else {
group_name="mkgroup";
}
}
I'd like to include some version of that information in the comment above
the case statement. My thinking is that if someone found where the
message is being generated, they are probably looking for more information
than "try running mkpasswd and mkgroup", so stating the meaning of the
special group names is probably warranted.
I'd also like to provide a bit more information in the statements that are
printed out to the user. Perhaps something like this (where the second
echo statement is new):
case `id -ng` in
mkpasswd )
echo "Your group is currently \"mkpasswd\". This indicates that"
echo "your gid is not in /etc/group and your uid is not in /etc/passwd."
echo "The /etc/passwd (and possibly /etc/group) files should be rebuilt."
echo "See the man pages for mkpasswd and mkgroup then, for example, run"
echo "mkpasswd -l [-d] > /etc/passwd"
echo "mkgroup -l [-d] > /etc/group"
echo "Note that the -d switch is necessary for domain users."
;;
To summarize, I'm proposing to:
* add the 'passwd/group_GID_clash' case
* delete the 'mkgroup_l_d' case
* provide definitions for the special group names in the comment above
the case statement
* modify the statements to the user to more accurately describe the
nature of the problem
Any opinions on if these modifications are a good idea or not?
Herb.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: cygwin bash crashes on Win Serv 2008
[not found] ` <corinna-cygwin@cygwin.com>
` (7 preceding siblings ...)
2008-10-15 5:43 ` Herb Maeder
@ 2008-10-23 19:18 ` Freddy Jensen
2008-10-24 17:05 ` [Fwd: Apologies for multiple messages (Please Help!)] Herb Maeder
` (9 subsequent siblings)
18 siblings, 0 replies; 77+ messages in thread
From: Freddy Jensen @ 2008-10-23 19:18 UTC (permalink / raw)
To: cygwin; +Cc: jensen
>From: Corinna Vinschen <corinna-cygwin@cygwin.com>
>Date: Thu Oct 23 2008 11:53am
>To: "cygwin@cygwin.com" <cygwin@cygwin.com>
>Subj: Re: cygwin bash crashes on Win Serv 2008
>
>On Oct 23 17:52, Dave Korn wrote:
>> Corinna Vinschen wrote on 23 October 2008 17:21:
>> > Attempt to execute non-executable address 00419d97
>> >
>> > Huh? Why should this address (this application function) be
>> > "non-executable", while it's executable when TS is not installed?
>>
>> DEP? ASLR? SafeSEH? As well as "dg" there are some other commands in
>> windbg that'll show you memory types and attributes.
>
>Huh! It was DEP. Apparently when installing TS, the default setting
>for DEP is switched from "Turn on DEP for essential Windows programs
>and services only" to "Turn on DEP for all programs and services
>[with execptions]". I switched it back, rebooted, and now bash, grep
>and GDB work fine.
>
Thanks everyone. Finding the root cause and
the workaround is a lifesaver for us.
Appreciate it.
Freddy
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: [Fwd: Apologies for multiple messages (Please Help!)]
[not found] ` <corinna-cygwin@cygwin.com>
` (8 preceding siblings ...)
2008-10-23 19:18 ` cygwin bash crashes on Win Serv 2008 Freddy Jensen
@ 2008-10-24 17:05 ` Herb Maeder
2008-10-24 17:29 ` Dave Korn
2008-11-07 17:52 ` [ANNOUNCEMENT] Updated: OpenSSH-5.1p1-6 (-7) Herb Maeder
` (8 subsequent siblings)
18 siblings, 1 reply; 77+ messages in thread
From: Herb Maeder @ 2008-10-24 17:05 UTC (permalink / raw)
To: overseers; +Cc: cygwin
On 24 Oct 2008 10:30:08 +0200, Corinna Vinschen wrote:
> we have a strange mail duplication here on the cygwin ML. The
> mail with Message ID <0ML4cO-1Kt7yy1h2s-000U3k@mx.kundenserver.de>
> is duplicated over and over again. Could something on sourceware
> be the culprit?
Now that is interesting! I see the message come back to me with no
Message-ID in the headers (sample included below, with '@' and '.'
replaced to protect the innocent).
I have a theory as to what's going on...
I believe that adding the Message-ID field is the responsibility of the
MUA. But some mail servers add a Message-ID if it is missing. I just
verified that my MUA was not creating the Message-ID field, and I'm
guessing that one got added somewhere along the way to Corinna's mailbox.
I don't think that the missing Message-ID is the root cause of the mail
duplication problem. But I do believe that the missing Message-ID causes
the workaround to the problem to fail. I'm guessing that the
sourceware.org server may detect and prevent duplicated messages based on
the Message-ID field. But since there wasn't one in my message, that
mechanism did not work.
(I've got a hunch that the root cause may be some miscommunication between
the servers due to timeouts or something, but I have no way to verify
that).
In any case, if my guess about the misssing Message-ID is correct, then
I believe that a few of things should be done:
1) I should make sure that my MUA generates the Message-ID field on
outgoing messages. I believe that I have fixed this now (and this
message should have a "@maeder.org" Message-ID).
2) If the cygwin mail server is truly depending on Message-ID to stop
this message duplication, it should somehow ensure that it is always
there. One option would be to prevent posts to the list that are
missing the Message-ID field (with some reasonable return error
message to the sender). NOTE: I'm not sure if generating a Message-ID
field on the cygwin mail server would work (that might just add
a unique Message-ID on each duplicated message, I'm not sure).
3) Determine and fix the root of the duplication problem (though I'm not
sure how feasible this would really be).
I think most modern MUA's add the Message-ID field, but it is not a strict
requirement. Implementing something for 2) above may help avoid the
duplication problem for mail sent from misconfigured and/or old school mail
clients (nmh in my case).
How to stop the still repeating evil message? I still haven't a clue...
Herb.
From cygwin-return-145237-maeder-cygml=maeder DOT org AT cygwin DOT com Thu Oct 23 20:44:41 2008
Return-Path: <cygwin-return-145237-maeder-cygml=maeder DOT org AT cygwin DOT com>
Delivered-To: maeder-cygml AT maeder DOT org
Received: (qmail 87667 invoked by uid 18834); 23 Oct 2008 20:44:41 -0000
Received: from unknown (HELO sourceware DOT org) ([209.132.176.174])
(envelope-sender <cygwin-return-145237-maeder-cygml=maeder DOT org AT cygwin DOT com>)
by 192.220.73.146 (qmail-ldap-1.03) with SMTP
for <maeder-cygml AT maeder DOT org>; 23 Oct 2008 20:44:41 -0000
Received: (qmail 31157 invoked by alias); 23 Oct 2008 20:44:40 -0000
Received: (qmail 31140 invoked by uid 22791); 23 Oct 2008 20:44:38 -0000
X-Spam-Check-By: sourceware DOT org
Received: from maeder DOT org (HELO maeder DOT org) (192.220.73.146) by sourceware DOT org (qpsmtpd/0.31) with ESMTP; Thu, 23 Oct 2008 20:43:33 +0000
Received: (qmail 86029 invoked by uid 18834); 23 Oct 2008 20:43:31 -0000
Received: from unknown (HELO maeder DOT org) ([127.0.0.1]) (envelope-sender <maeder-cygml AT maeder DOT org>) by 127.0.0.1 (qmail-ldap-1.03) with SMTP for <cygwin AT cygwin DOT com>; 23 Oct 2008 20:43:31 -0000
To: cygwin AT cygwin DOT com
From: Herb Maeder <maeder-cygml AT maeder DOT org>
In-reply-to: "Manning, Sid" <sidneym AT qualcomm DOT com> 's message of Mon, 20 Oct 2008 11:53:19 PDT.
Subject: Re: Compile time Local Cygwin vs. VMware session on same system
Date: Thu, 23 Oct 2008 13:43:30 -0700
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin DOT com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-maeder-cygml=maeder DOT org AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware DOT org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware DOT org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Status: RO
X-Status:
X-Keywords:
X-UID: 4142
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 77+ messages in thread* RE: [Fwd: Apologies for multiple messages (Please Help!)]
2008-10-24 17:05 ` [Fwd: Apologies for multiple messages (Please Help!)] Herb Maeder
@ 2008-10-24 17:29 ` Dave Korn
0 siblings, 0 replies; 77+ messages in thread
From: Dave Korn @ 2008-10-24 17:29 UTC (permalink / raw)
To: 'Herb Maeder', overseers; +Cc: cygwin
Herb Maeder wrote on 24 October 2008 18:05:
> I have a theory as to what's going on...
>
> I believe that adding the Message-ID field is the responsibility of the
> MUA.
Yep.
> But some mail servers add a Message-ID if it is missing.
Yep. In my case, it gets added at my local server when I receive the post
from sourceware.org.
> I don't think that the missing Message-ID is the root cause of the mail
> duplication problem. But I do believe that the missing Message-ID causes
> the workaround to the problem to fail.
Yep and yep.
> I'm guessing that the
> sourceware.org server may detect and prevent duplicated messages based on
> the Message-ID field.
Yep, this is a standard dup-filtering strategy for MTAs.
> But since there wasn't one in my message, that
> mechanism did not work.
Indeed it could not.
> (I've got a hunch that the root cause may be some miscommunication between
> the servers due to timeouts or something, but I have no way to verify
> that).
You don't have access to the maeder.org server?
> In any case, if my guess about the misssing Message-ID is correct, then
> I believe that a few of things should be done:
>
> 1) I should make sure that my MUA generates the Message-ID field on
> outgoing messages. I believe that I have fixed this now (and this
> message should have a "@maeder.org" Message-ID).
Confirmed.
> 2) If the cygwin mail server is truly depending on Message-ID to stop
> this message duplication, it should somehow ensure that it is always
> there. One option would be to prevent posts to the list that are
> missing the Message-ID field (with some reasonable return error
> message to the sender). NOTE: I'm not sure if generating a
> Message-ID field on the cygwin mail server would work (that might
> just add a unique Message-ID on each duplicated message, I'm not
> sure).
Well, it might be possible to make a msgid based on a hash of the body of
the email. But that would have the consequence of making it easier to impose
a computational-load DoS on the machine by sending it lots of spam with no
msgid headers. Probably an outright rejection would be best.
> 3) Determine and fix the root of the duplication problem (though I'm not
> sure how feasible this would really be).
> How to stop the still repeating evil message? I still haven't a clue...
Those headers you showed us are completely conclusive:
> >From message 1:
> Received: from maeder.org (HELO maeder.org) (192.220.73.146) by
sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 23 Oct 2008 20:43:33 +0000
> Received: (qmail 86029 invoked by uid 18834); 23 Oct 2008 20:43:31 -0000
>
> >From message 2:
> Received: from maeder.org (HELO maeder.org) (192.220.73.146) by
sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 23 Oct 2008 20:50:13 +0000
> Received: (qmail 86029 invoked by uid 18834); 23 Oct 2008 20:43:31 -0000
>
> >From message 3:
> Received: from maeder.org (HELO maeder.org) (192.220.73.146) by
sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 23 Oct 2008 21:10:13 +0000
> Received: (qmail 86029 invoked by uid 18834); 23 Oct 2008 20:43:31 -0000
What this shows is that maeder.org (192.220.73.146) is repeatedly contacting
sourceware.org to deliver the mail. You sent the mail once only - the
repeated (qmail invoked by uid) lines all have the same stamp; your local MTA
accepted and spooled it, and is trying to send it to sourceware.org. Because
it has no msgid, sourceware.org thinks it's a new message every time. The
problem is caused by the fact that sourceware.org accepts the post, but
maeder.org thinks it hasn't, and retries a while later (looks like a slowly
increasing backoff is involved).
You need to look at the mail logs on maeder.org and see what it thinks has
happened during the conversation at sourceware.org. It may be that
sourceware.org is bogusly both accepting the mail and yet indicating an error
code to maeder.org, or it may be that maeder.org is misinterpreting the status
code from sourceware.org and only thinking it means "not accepted" when it in
fact means something like "accepted with warnings".
I don't have access to the sourceware logs, but you may be able to read
/var/log/maillog on maeder.org even if you only have standard user-level
access, it's quite common not to need root access just to read the logs.
cheers,
DaveK
--
Can't think of a witty .sigline today....
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [ANNOUNCEMENT] Updated: OpenSSH-5.1p1-6 (-7)
[not found] ` <corinna-cygwin@cygwin.com>
` (9 preceding siblings ...)
2008-10-24 17:05 ` [Fwd: Apologies for multiple messages (Please Help!)] Herb Maeder
@ 2008-11-07 17:52 ` Herb Maeder
2008-11-07 18:36 ` Christopher Faylor
2008-11-07 21:17 ` Herb Maeder
` (7 subsequent siblings)
18 siblings, 1 reply; 77+ messages in thread
From: Herb Maeder @ 2008-11-07 17:52 UTC (permalink / raw)
To: cygwin
On 07 Nov 2008 12:00:56 +0100, Corinna Vinschen wrote:
> I've just updated the version of OpenSSH to 5.1p1-6.
>
> This is a bugfix release which fixes a bug in the ssh-host-config script
> which stumbles over user names with a substring of "ssh" in them and
> thinks that ssh processes are still running.
>
> There's an equivalent new 5.1p1-7 release for Cygwin 1.7 testers.
It seems that setup-2.ini on the mirrors is actually pointing to 5.1p1-6,
which does not exist in release-2.
It looks like the modification time of the tarball is 3 minutes after
setup-2.ini, so perhaps setup-2.ini just needs to be regenerated.
Herb.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: [ANNOUNCEMENT] Updated: OpenSSH-5.1p1-6 (-7)
2008-11-07 17:52 ` [ANNOUNCEMENT] Updated: OpenSSH-5.1p1-6 (-7) Herb Maeder
@ 2008-11-07 18:36 ` Christopher Faylor
0 siblings, 0 replies; 77+ messages in thread
From: Christopher Faylor @ 2008-11-07 18:36 UTC (permalink / raw)
To: cygwin
On Fri, Nov 07, 2008 at 09:51:24AM -0800, Herb Maeder wrote:
>On 07 Nov 2008 12:00:56 +0100, Corinna Vinschen wrote:
>> I've just updated the version of OpenSSH to 5.1p1-6.
>>
>> This is a bugfix release which fixes a bug in the ssh-host-config script
>> which stumbles over user names with a substring of "ssh" in them and
>> thinks that ssh processes are still running.
>>
>> There's an equivalent new 5.1p1-7 release for Cygwin 1.7 testers.
>
>It seems that setup-2.ini on the mirrors is actually pointing to 5.1p1-6,
>which does not exist in release-2.
>
>It looks like the modification time of the tarball is 3 minutes after
>setup-2.ini, so perhaps setup-2.ini just needs to be regenerated.
There have been some problems regenerating setup-2.ini today. I'm waiting
for some package maintainers to fill me in on what's going on with their
packages so that we can fix the problem.
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [ANNOUNCEMENT] Updated: OpenSSH-5.1p1-6 (-7)
[not found] ` <corinna-cygwin@cygwin.com>
` (10 preceding siblings ...)
2008-11-07 17:52 ` [ANNOUNCEMENT] Updated: OpenSSH-5.1p1-6 (-7) Herb Maeder
@ 2008-11-07 21:17 ` Herb Maeder
2008-11-07 21:38 ` Herb Maeder
` (6 subsequent siblings)
18 siblings, 0 replies; 77+ messages in thread
From: Herb Maeder @ 2008-11-07 21:17 UTC (permalink / raw)
To: cygwin
On 07 Nov 2008 12:00:56 +0100, Corinna Vinschen wrote:
> This is a bugfix release which fixes a bug in the ssh-host-config script
> which stumbles over user names with a substring of "ssh" in them and
> thinks that ssh processes are still running.
>
> There's an equivalent new 5.1p1-7 release for Cygwin 1.7 testers.
It looks like there may be a problem with the ssh-host-config in the
5.1p1-7 release. It now uses "mount -t", but the -t option is no longer
valid in the 1.7 version of mount.
% ssh-host-config
*** Info: Creating default /etc/ssh_config file
*** Info: Creating default /etc/sshd_config file
*** Info: Privilege separation is set to yes by default since OpenSSH 3.3.
*** Info: However, this requires a non-privileged account called 'sshd'.
*** Info: For more info on privilege separation read /usr/share/doc/openssh/README.privsep.
*** Query: Should privilege separation be used? (yes/no) yes
*** Info: Updating /etc/sshd_config file
mount: unknown option -- t
Usage: mount [OPTION] [<win32path> <posixpath>]
Display information about mounted filesystems, or mount a filesystem
-c, --change-cygdrive-prefix change the cygdrive path prefix to <posixpath>
-f, --force force mount, don't warn about missing mount
point directories
-h, --help output usage information and exit
-m, --mount-entries write fstab entries to replicate mount points
and cygdrive prefixes
-o, --options X[,X...] specify mount options
-p, --show-cygdrive-prefix show user and/or system cygdrive path prefix
-v, --version output version information and exit
Valid options are:
binary,text,exec,notexec,cygexec,nosuid,acl,noacl,posix=1,posix=0
grep: /ssh-host-config.2052/services: No such file or directory
grep: /ssh-host-config.2052/services: No such file or directory
/usr/bin/ssh-host-config: line 105: /ssh-host-config.2052/services: No such file or directory
*** Warning: Adding ssh to C:umount: /ssh-host-config.2052: Invalid argument
*** Warning: The following functions require administrator privileges!
*** Query: Do you want to install sshd as a service?
This is on a vista machine with a clean 1.7 install (with openssh-5.1p1-7
installed from a local mirror since the public mirrors are broken right now).
Switching it back to "mount -o text" seems to work (I'm not sure if that
should be made conditional on 1.7 though).
Herb.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: [ANNOUNCEMENT] Updated: OpenSSH-5.1p1-6 (-7)
[not found] ` <corinna-cygwin@cygwin.com>
` (11 preceding siblings ...)
2008-11-07 21:17 ` Herb Maeder
@ 2008-11-07 21:38 ` Herb Maeder
2008-11-07 22:10 ` Christopher Faylor
2008-11-13 1:54 ` sshd on vista error "initgroups: Permission denied" (cygwin-1.7) Herb Maeder
` (5 subsequent siblings)
18 siblings, 1 reply; 77+ messages in thread
From: Herb Maeder @ 2008-11-07 21:38 UTC (permalink / raw)
To: cygwin
On 07 Nov 2008 12:00:56 +0100, Corinna Vinschen wrote:
> This is a bugfix release which fixes a bug in the ssh-host-config script
> which stumbles over user names with a substring of "ssh" in them and
> thinks that ssh processes are still running.
Is the intent now to catch only processes named 'sshd'? If so, the
current "grep -q 'sshd*$'" may still be a little too loose. For example,
it could match stuff like "/home/user/flosshdd". Ok, maybe not likely,
but still it would cause the script to end in an error.
Assuming we can depend on "ps -ef" always printing full path names without
any arguments, then "grep -q '/sshd$'" might do the trick. Is there any
reason to catch multiple trailing d's?
If a more loose matching scheme is really desired, it might be helpful to
print out the matching ps lines before generating the error (just so
that it's more obvious to the user as to what is going on).
Sorry if this is too nit-picky. I just happened to notice it when I was
looking at other stuff.
Herb.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: [ANNOUNCEMENT] Updated: OpenSSH-5.1p1-6 (-7)
2008-11-07 21:38 ` Herb Maeder
@ 2008-11-07 22:10 ` Christopher Faylor
0 siblings, 0 replies; 77+ messages in thread
From: Christopher Faylor @ 2008-11-07 22:10 UTC (permalink / raw)
To: cygwin
On Fri, Nov 07, 2008 at 01:37:44PM -0800, Herb Maeder wrote:
>On 07 Nov 2008 12:00:56 +0100, Corinna Vinschen wrote:
>> This is a bugfix release which fixes a bug in the ssh-host-config script
>> which stumbles over user names with a substring of "ssh" in them and
>> thinks that ssh processes are still running.
>
>Is the intent now to catch only processes named 'sshd'? If so, the
>current "grep -q 'sshd*$'" may still be a little too loose. For example,
>it could match stuff like "/home/user/flosshdd". Ok, maybe not likely,
>but still it would cause the script to end in an error.
>
>Assuming we can depend on "ps -ef" always printing full path names without
>any arguments, then "grep -q '/sshd$'" might do the trick. Is there any
>reason to catch multiple trailing d's?
It's possible that Corinna was looking for zero or more d's.
So, something like grep -qP '/sshd?' would accommodate that.
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: sshd on vista error "initgroups: Permission denied" (cygwin-1.7)
[not found] ` <corinna-cygwin@cygwin.com>
` (12 preceding siblings ...)
2008-11-07 21:38 ` Herb Maeder
@ 2008-11-13 1:54 ` Herb Maeder
2008-11-13 14:51 ` Corinna Vinschen
2008-11-14 7:31 ` Herb Maeder
` (4 subsequent siblings)
18 siblings, 1 reply; 77+ messages in thread
From: Herb Maeder @ 2008-11-13 1:54 UTC (permalink / raw)
To: cygwin
On 10 Nov 2008 15:48:15 +0100, Corinna Vinschen wrote:
> On Nov 8 07:44, Herb Maeder wrote:
> > Running sshd (openssh 5.1p1-d57 or 5.1p1-7) on cygwin-1.7 and vista
> > results in the following error:
> >
> > % ssh localhost pwd
> > herb@localhost's password:
> > initgroups: Permission denied
> >
> > I think this should be easily reproducible with a fresh installation of
> > just cygwin 1.7 base + openssh running on a generic vista confiuration
> > with UAC enabled.
> >
> > Can anyone confirm this? If it is specific to my setup, I'll dig deeper
> > and provide more information.
>
> I can't reproduce this. A permission denied in initgroups point to
> insufficient privileges of the account running sshd. Are you running
> sshd with a local cyg_server account but trying to login with a domain
> account? Maybe there's a permission problem.
You are correct. I was indeed running sshd with a local cyg_server, but
logging in with a domain account. I tried firing up sshd as me, and I was
able to log in successfully. Thanks for pointing me in the right
direction.
I think this means that "ssh-host-config -y" followed by "cygrunsrv
--start sshd" no longer works for setting up sshd for domain users
on vista (though it still does on XP). What should be the recommended
procedure for setting up sshd on Vista + cygwin-1.7?
Am I correct in assuming that you would need to have access to an account
with Domain Administrator privileges in order to allow multiple domain
users to ssh into a 1.7 vista machine?
And if you don't have access to such an account, the best you can do is
fire up sshd as yourself (or perhaps one sshd per user on different ports)?
I'm guessing that will allow you and local users to ssh in (assuming your
domain account has local administrator access).
Looking ahead, I suspect that this combo (sshd + 1.7 + vista + domain user)
will be pretty common. Is there a plan for steering users in the right
direction during the setup of sshd, or maybe giving a more descriptive
error message?
> 1. Yes, ssh-host-config has to be run elevated, as with all applications
> requiring actual admin privileges. There's no way to elevate a child
> process running in the same console window. Microsoft tweaked the
> ShellExecute() call in shell32.dll heavily to allow the UAC stuff,
> but neglected to allow applications using the CreateProcess() call to
> do the same. ShellExecute is not an option to use in Cygwin processes.
Bum deal. But thanks for the explanation. That clarifies what I was
seeing.
Herb.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: sshd on vista error "initgroups: Permission denied" (cygwin-1.7)
2008-11-13 1:54 ` sshd on vista error "initgroups: Permission denied" (cygwin-1.7) Herb Maeder
@ 2008-11-13 14:51 ` Corinna Vinschen
2008-11-13 15:29 ` Corinna Vinschen
0 siblings, 1 reply; 77+ messages in thread
From: Corinna Vinschen @ 2008-11-13 14:51 UTC (permalink / raw)
To: cygwin
On Nov 12 16:57, Herb Maeder wrote:
> On 10 Nov 2008 15:48:15 +0100, Corinna Vinschen wrote:
> [...]
> Am I correct in assuming that you would need to have access to an account
> with Domain Administrator privileges in order to allow multiple domain
> users to ssh into a 1.7 vista machine?
I'm not quite sure about this. I don't claim to understand all the does
and dont's of Windows domains either.
However, I have a working result by creating a domain account with the
required permissions called cyg_server, then create a cyg_server entry
in passwd using mkpasswd, then start ssh-host-coonfig.
> And if you don't have access to such an account, the best you can do is
> fire up sshd as yourself (or perhaps one sshd per user on different ports)?
> I'm guessing that will allow you and local users to ssh in (assuming your
> domain account has local administrator access).
>
> Looking ahead, I suspect that this combo (sshd + 1.7 + vista + domain user)
> will be pretty common. Is there a plan for steering users in the right
> direction during the setup of sshd, or maybe giving a more descriptive
> error message?
The ssh-host-config script only covers the simpler approaches for home
users. Right now, a professional administrator for a Windows domain
will have to know a bit, or ask here.
Ideally, somebody would take a heart and
- Add more code to ssh-host-config to allow more smooth operations
in a domain environment.
- Add to the documentation to explain the problems.
But right now that won't be me.
> > 1. Yes, ssh-host-config has to be run elevated, as with all applications
> > requiring actual admin privileges. There's no way to elevate a child
> > process running in the same console window. Microsoft tweaked the
> > ShellExecute() call in shell32.dll heavily to allow the UAC stuff,
> > but neglected to allow applications using the CreateProcess() call to
> > do the same. ShellExecute is not an option to use in Cygwin processes.
>
> Bum deal. But thanks for the explanation. That clarifies what I was
> seeing.
Actually there is a way to elevate a console application which is the
manifest file. Unfortunately this only works for executables, not for
scripts.
I didn't try it myself, but maybe something like this works:
$ cd /bin
$ cp bash.exe bash-elevated.exe
$ sed 's/nstall\.exe/bash-elevated.exe/g' < install.exe > bash-elevated.exe.manifest
$ sed '1s/bash/bash-elevated/' < ssh-host-config > ssh-host-config-elevated
$ ssh-host-config-elevated
Sometimes adding a manifest file to an executable doesn't work immediately
due to some cashing in Windows but basically this should work.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: sshd on vista error "initgroups: Permission denied" (cygwin-1.7)
2008-11-13 14:51 ` Corinna Vinschen
@ 2008-11-13 15:29 ` Corinna Vinschen
0 siblings, 0 replies; 77+ messages in thread
From: Corinna Vinschen @ 2008-11-13 15:29 UTC (permalink / raw)
To: cygwin
On Nov 13 11:35, Corinna Vinschen wrote:
> On Nov 12 16:57, Herb Maeder wrote:
> > Bum deal. But thanks for the explanation. That clarifies what I was
> > seeing.
>
> Actually there is a way to elevate a console application which is the
> manifest file. Unfortunately this only works for executables, not for
> scripts.
>
> I didn't try it myself, but maybe something like this works:
>
> $ cd /bin
> $ cp bash.exe bash-elevated.exe
> $ sed 's/nstall\.exe/bash-elevated.exe/g' < install.exe > bash-elevated.exe.manifest
> $ sed '1s/bash/bash-elevated/' < ssh-host-config > ssh-host-config-elevated
> $ ssh-host-config-elevated
>
> Sometimes adding a manifest file to an executable doesn't work immediately
> due to some cashing in Windows but basically this should work.
On second thought, this can't work. The manifest file starts the
application with an execution level of "asInvoker" which means *not*
elevated. Even if you change this to elevated (I don't know the right
level string for this off hand), the problem that you won't get an
elevation prompt when a process gets started through CreateProcess
remains the same. Too bad. The mainfests work in one direction, but
they don't in the other. Baeh.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: sshd on vista error "initgroups: Permission denied" (cygwin-1.7)
[not found] ` <corinna-cygwin@cygwin.com>
` (13 preceding siblings ...)
2008-11-13 1:54 ` sshd on vista error "initgroups: Permission denied" (cygwin-1.7) Herb Maeder
@ 2008-11-14 7:31 ` Herb Maeder
2008-11-14 11:24 ` Corinna Vinschen
2008-11-20 4:25 ` Herb Maeder
` (3 subsequent siblings)
18 siblings, 1 reply; 77+ messages in thread
From: Herb Maeder @ 2008-11-14 7:31 UTC (permalink / raw)
To: cygwin
On 13 Nov 2008 14:57:20 +0100, Corinna Vinschen wrote:
> On Nov 13 11:35, Corinna Vinschen wrote:
> > On Nov 12 16:57, Herb Maeder wrote:
> > > Bum deal. But thanks for the explanation. That clarifies what I was
> > > seeing.
> >
> > Actually there is a way to elevate a console application which is the
> > manifest file. Unfortunately this only works for executables, not for
> > scripts.
> >
> > I didn't try it myself, but maybe something like this works:
> >
> > $ cd /bin
> > $ cp bash.exe bash-elevated.exe
> > $ sed 's/nstall\.exe/bash-elevated.exe/g' < install.exe > bash-elevated.e
xe.manifest
> > $ sed '1s/bash/bash-elevated/' < ssh-host-config > ssh-host-config-elevat
ed
> > $ ssh-host-config-elevated
> >
> > Sometimes adding a manifest file to an executable doesn't work immediately
> > due to some cashing in Windows but basically this should work.
>
> On second thought, this can't work. The manifest file starts the
> application with an execution level of "asInvoker" which means *not*
> elevated. Even if you change this to elevated (I don't know the right
> level string for this off hand), the problem that you won't get an
> elevation prompt when a process gets started through CreateProcess
> remains the same. Too bad. The mainfests work in one direction, but
> they don't in the other. Baeh.
Yeah, I think that corresponds to what I found... there's no way to
elevate a command without somehow firing off another application like a
separate cmd window.
Along similar lines, I tried to "cp /bin/bash.exe /bin/bash-elev.exe",
then set bash-elev to run as adminstrator, with Right Click -> Properties ->
Compatibility then check the "Run this program as an administrator" box.
There was no love when invoking bash-elev.exe directly from a bash command
line, but invoking it via a cmd shell did the trick.
The best I was able to do was to create an "elev.sh" script like this:
#!/bin/bash
eval 'cmd /c bash-elev -c '\'${1+"$@"}\'''
I know that the quoting is not quite right to deal with all possible
arguments correctly, but it should be good enough to fire off some generic
elevated commands.
For example:
elev.sh /bin/ssh-host-config -y
or even something like this will work:
elev.sh "/bin/bash somescript.sh \"a b\" c > out; sleep 4"
If elev.sh is called from an already elevated bash shell (run with "Run as
administrator"), then there will be no UAC prompt and the output will
appear normally in the shell. But if the invoking shell is not elevated,
then it will display the UAC prompt, and fire off a separate cmd shell
window. The bummer is that for normal commands, any output will be
displayed in the new cmd window, which will exit immediately (i.e. user
won't see the output). Though it is possible to redirect the output to
a file.
Still, even with these drawbacks, something like this might be useful for
us in ssh-host-config. If the invoking shell is already elevated, things
will pretty much work the way they do now. But if it is invoked from a
normal shell, the user would get prompted to elevate, and then the
ssh-host-config queries and input would happen in a different cmd window.
Not great, but still better than just exiting with an error (or, worse,
trying to continue with insufficient privileges).
Herb.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: sshd on vista error "initgroups: Permission denied" (cygwin-1.7)
2008-11-14 7:31 ` Herb Maeder
@ 2008-11-14 11:24 ` Corinna Vinschen
0 siblings, 0 replies; 77+ messages in thread
From: Corinna Vinschen @ 2008-11-14 11:24 UTC (permalink / raw)
To: cygwin
On Nov 13 15:48, Herb Maeder wrote:
> Still, even with these drawbacks, something like this might be useful for
> us in ssh-host-config. If the invoking shell is already elevated, things
> will pretty much work the way they do now. But if it is invoked from a
> normal shell, the user would get prompted to elevate, and then the
> ssh-host-config queries and input would happen in a different cmd window.
> Not great, but still better than just exiting with an error (or, worse,
> trying to continue with insufficient privileges).
Actually this isn't a ssh-host-config problem, but a generic problem
for all admin tasks. Installing any service requires elevation, or
running in a Admin shell. I'm not really convinced that we need it.
Admins running admin tasks should know that they need admin privileges.
What you're asking for is a convenience, not a necessity.
Having said that, if we want that I think the Vista elevation stuff
should go into csih, rather than ssh-host-config script, so all admin
scripts can use the functionality easily in the long run.
And I'm sure Charles wouldn't mind to get csih patches ;)
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: sshd on vista error "initgroups: Permission denied" (cygwin-1.7)
[not found] ` <corinna-cygwin@cygwin.com>
` (14 preceding siblings ...)
2008-11-14 7:31 ` Herb Maeder
@ 2008-11-20 4:25 ` Herb Maeder
2008-11-20 6:35 ` Herb Maeder
` (2 subsequent siblings)
18 siblings, 0 replies; 77+ messages in thread
From: Herb Maeder @ 2008-11-20 4:25 UTC (permalink / raw)
To: cygwin
On 13 Nov 2008 11:35:43 +0100, Corinna Vinschen wrote:
> > Looking ahead, I suspect that this combo (sshd + 1.7 + vista + domain user)
> > will be pretty common. Is there a plan for steering users in the right
> > direction during the setup of sshd, or maybe giving a more descriptive
> > error message?
>
> The ssh-host-config script only covers the simpler approaches for home
> users. Right now, a professional administrator for a Windows domain
> will have to know a bit, or ask here.
>
> Ideally, somebody would take a heart and
>
> - Add more code to ssh-host-config to allow more smooth operations
> in a domain environment.
> - Add to the documentation to explain the problems.
>
> But right now that won't be me.
Understood. Thanks for providing the game plan in any case.
As for me, I've unfortunately just lost all access to my domain account
and vista test machines. So, although I would like help, I don't think
that I'll be able to accomplish much on this front in the short term. But
I'll see what I can do to get the ball rolling in the right direction.
Is this the appropriate document to update with an explanation of the
problems?
/usr/share/doc/Cygwin/openssh.README
Herb.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: sshd on vista error "initgroups: Permission denied" (cygwin-1.7)
[not found] ` <corinna-cygwin@cygwin.com>
` (15 preceding siblings ...)
2008-11-20 4:25 ` Herb Maeder
@ 2008-11-20 6:35 ` Herb Maeder
2008-11-20 10:46 ` Corinna Vinschen
2008-11-20 23:41 ` Herb Maeder
2009-02-16 16:16 ` Does CYGWIN work on Windows 2008 x86 architecture ? Freddy Jensen
18 siblings, 1 reply; 77+ messages in thread
From: Herb Maeder @ 2008-11-20 6:35 UTC (permalink / raw)
To: cygwin
On 14 Nov 2008 10:53:12 +0100, Corinna Vinschen wrote:
> Actually this isn't a ssh-host-config problem, but a generic problem
> for all admin tasks. Installing any service requires elevation, or
> running in a Admin shell. I'm not really convinced that we need it.
> Admins running admin tasks should know that they need admin privileges.
> What you're asking for is a convenience, not a necessity.
Yes, I agree that we are talking about a generic problem for tasks
requiring elevation. And perhaps I took it a step too far suggesting that
we might want to provide a mechanism to elevate automatically (a lame
attempt at being compatible with pre-vista OSes). So I take that back.
I'd really just like to understand what the recommended behavior should be
for admin tasks that are invoked from underprivileged shells under vista
with UAC turned on. In other words, should we do anything to ease a
cygwin user's transition to Vista?
Right now, the documentation doesn't address any migration to vista
issues. So we are pretty much ensuring that new vista users will stumble
onto the cygwin elevation problems the hard way. And this list or its
archives are the only resources to figure out what to do. We can do
better than that.
Bottom line, any design decision that reduces noise on this list will have
the added benefit of providing a better experience to the user (win-win).
Or put differently, an inconvience to the user can translate to an
inconvenience to the list.
For example, would these be reasonable goals for admin tasks requiring
elevation?
* Provide documentation and recommendations for vista specific issues
(UAC recommendations, how to elevate, commands requiring
elevation,...). Is the user guide the right place for that?
* When a command requires elevation, detect if the process is already
elevated. If not, exit with an error and a reasonable error statement
indicating the nature of the problem (and perhaps point to the more
detailed documentation and recommendations on how to address the
problem above).
Any others?
Note, I'm not requesting any changes. I'm just trying to understand if we
could/should establish guidelines for admin tasks requiring elevation.
> Having said that, if we want that I think the Vista elevation stuff
> should go into csih, rather than ssh-host-config script, so all admin
> scripts can use the functionality easily in the long run.
That certainly makes sense for admin scripts. Though it would be good if
other admin commands would also behave similarly.
> And I'm sure Charles wouldn't mind to get csih patches ;)
Gots to understand the design goals before attempting any patches...
Herb.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: sshd on vista error "initgroups: Permission denied" (cygwin-1.7)
2008-11-20 6:35 ` Herb Maeder
@ 2008-11-20 10:46 ` Corinna Vinschen
0 siblings, 0 replies; 77+ messages in thread
From: Corinna Vinschen @ 2008-11-20 10:46 UTC (permalink / raw)
To: cygwin
On Nov 19 17:38, Herb Maeder wrote:
> On 14 Nov 2008 10:53:12 +0100, Corinna Vinschen wrote:
> > Actually this isn't a ssh-host-config problem, but a generic problem
> > for all admin tasks. Installing any service requires elevation, or
> > running in a Admin shell. I'm not really convinced that we need it.
> > Admins running admin tasks should know that they need admin privileges.
> > What you're asking for is a convenience, not a necessity.
>
> Yes, I agree that we are talking about a generic problem for tasks
> requiring elevation. And perhaps I took it a step too far suggesting that
> we might want to provide a mechanism to elevate automatically (a lame
> attempt at being compatible with pre-vista OSes). So I take that back.
>
> I'd really just like to understand what the recommended behavior should be
> for admin tasks that are invoked from underprivileged shells under vista
> with UAC turned on. In other words, should we do anything to ease a
> cygwin user's transition to Vista?
>
> Right now, the documentation doesn't address any migration to vista
> issues. So we are pretty much ensuring that new vista users will stumble
> onto the cygwin elevation problems the hard way. And this list or its
> archives are the only resources to figure out what to do. We can do
> better than that.
>
> Bottom line, any design decision that reduces noise on this list will have
> the added benefit of providing a better experience to the user (win-win).
> Or put differently, an inconvience to the user can translate to an
> inconvenience to the list.
>
> For example, would these be reasonable goals for admin tasks requiring
> elevation?
>
> * Provide documentation and recommendations for vista specific issues
> (UAC recommendations, how to elevate, commands requiring
> elevation,...). Is the user guide the right place for that?
>
> * When a command requires elevation, detect if the process is already
> elevated. If not, exit with an error and a reasonable error statement
> indicating the nature of the problem (and perhaps point to the more
> detailed documentation and recommendations on how to address the
> problem above).
>
> Any others?
>
> Note, I'm not requesting any changes. I'm just trying to understand if we
> could/should establish guidelines for admin tasks requiring elevation.
All nice points but I don't think that you have to convince anybody that
better documentation and scripts which work better in any environment
are preferrable. The point is, http://cygwin.com/acronyms/#SHTDI
We can discuss stuff like that at great length but it won't help
anybody if the docs and code doesn't get fixed along these lines.
Be a part of the project and suggest documentation patches as you see
fit, or create code patches for scripts to make them more intelligent.
That would help other users and us maintainers a lot. None of us has
access to all possible environments/systems and can care for all border
cases. Or take the next step and be a maintainer yourself. In most
cases it's not as much work in the long run as you think it is in the
beginning (when creating your package(s) the first time).
Talking about Vista migration. From Cygwin's point of view Vista
is just another OS. The user is just another user. Either the user
has certain privileges or not. A function works or returns EACCES.
That's all. Elevation is not an issue for Cygwin, for pretty dumb
technical reasons. The only concession *I* would be willing to make
(but that's just me) is to add some text to admin scripts along these
lines:
*** Alarm! I couldn't create file foo.
*** You're missing privileges. If you're admin user and running
*** on Vista, did you think to run the script in an elevated shell?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: sshd on vista error "initgroups: Permission denied" (cygwin-1.7)
[not found] ` <corinna-cygwin@cygwin.com>
` (16 preceding siblings ...)
2008-11-20 6:35 ` Herb Maeder
@ 2008-11-20 23:41 ` Herb Maeder
2008-11-20 23:53 ` Herb Maeder
` (7 more replies)
2009-02-16 16:16 ` Does CYGWIN work on Windows 2008 x86 architecture ? Freddy Jensen
18 siblings, 8 replies; 77+ messages in thread
From: Herb Maeder @ 2008-11-20 23:41 UTC (permalink / raw)
To: cygwin
On 20 Nov 2008 11:37:23 +0100, Corinna Vinschen wrote:
> > Note, I'm not requesting any changes. I'm just trying to understand if we
> > could/should establish guidelines for admin tasks requiring elevation.
>
> All nice points but I don't think that you have to convince anybody that
> better documentation and scripts which work better in any environment
> are preferrable. The point is, http://cygwin.com/acronyms/#SHTDI
> We can discuss stuff like that at great length but it won't help
> anybody if the docs and code doesn't get fixed along these lines.
OTOH, if you can't discuss stuff before patching, you're more likely to
get garbage. Witness the last guy who tried.
> Be a part of the project and suggest documentation patches as you see
> fit, or create code patches for scripts to make them more intelligent.
Um, that's what I was trying to do. It just that I'm not a big fan of the
"patch first, discuss later" philosophy, especially when I'm in unfamiliar
territory. I usually try to get agreement on a gameplan first, then
execute.
Lucky for me too, since what I saw fit was already wrong twice on this
elevation issue...
> That would help other users and us maintainers a lot. None of us has
> access to all possible environments/systems and can care for all border
> cases. Or take the next step and be a maintainer yourself. In most
> cases it's not as much work in the long run as you think it is in the
> beginning (when creating your package(s) the first time).
I'm probably not maintainer material. I don't care to discuss it on this
list, but it has nothing to do with the mechanics of maintaining a
package. If you'd like to discuss it or convince me otherwise, you may
contact me personally.
> Talking about Vista migration. From Cygwin's point of view Vista
> is just another OS. The user is just another user. Either the user
> has certain privileges or not. A function works or returns EACCES.
> That's all. Elevation is not an issue for Cygwin, for pretty dumb
> technical reasons.
Though it is an issue from the cygwin user's point of view.
But I do understand where you are coming from. Microsoft also took the
same approach (nothing was done to ease the pain of using Windows command
line tools requiring elevation). Not that that necessarily makes it
http://acronyms.thefreedictionary.com/TRTTD ...
> The only concession *I* would be willing to make
> (but that's just me) is to add some text to admin scripts along these
> lines:
>
> *** Alarm! I couldn't create file foo.
> *** You're missing privileges. If you're admin user and running
> *** on Vista, did you think to run the script in an elevated shell?
That's actually decently close to what I was asking about. Though the
error statement could be qualified with (onVista && !elevated), and some
scripts which don't make sense without elevation (e.g. ssh-host-config)
could just test for that right from the get-go. Plus there's no reason
that compiled commands couldn't do something similar (e.g. "regtool add").
Any code requiring elevation is obviously already cygwin specific.
But, it sounds to me like that is not worth doing and/or not desirable.
That's a perfectly good answer. And I'm fine with that, believe me. An
answer is all I was looking for.
So, to summarize this thread and move on:
1) vista specific documentation is welcome
2) patches to csih/ssh-host-config for 1.7+vista+domain users are welcome
3) patches for elevation issues are not
I'm willing to take a whack at 1), so if anyone has any specific topics
that should be covered or any hints on where this documentation belongs,
please let me know. Else, I'll just do as I see fit.
I sould also like to address 2), but I am now in the boat of not having
access to the required environments/systems. So I can't commit to that
one.
Herb.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: sshd on vista error "initgroups: Permission denied" (cygwin-1.7)
2008-11-20 23:41 ` Herb Maeder
@ 2008-11-20 23:53 ` Herb Maeder
2008-11-21 0:18 ` Matthew Woehlke
` (6 subsequent siblings)
7 siblings, 0 replies; 77+ messages in thread
From: Herb Maeder @ 2008-11-20 23:53 UTC (permalink / raw)
To: cygwin
On 20 Nov 2008 11:37:23 +0100, Corinna Vinschen wrote:
> > Note, I'm not requesting any changes. I'm just trying to understand if we
> > could/should establish guidelines for admin tasks requiring elevation.
>
> All nice points but I don't think that you have to convince anybody that
> better documentation and scripts which work better in any environment
> are preferrable. The point is, http://cygwin.com/acronyms/#SHTDI
> We can discuss stuff like that at great length but it won't help
> anybody if the docs and code doesn't get fixed along these lines.
OTOH, if you can't discuss stuff before patching, you're more likely to
get garbage. Witness the last guy who tried.
> Be a part of the project and suggest documentation patches as you see
> fit, or create code patches for scripts to make them more intelligent.
Um, that's what I was trying to do. It just that I'm not a big fan of the
"patch first, discuss later" philosophy, especially when I'm in unfamiliar
territory. I usually try to get agreement on a gameplan first, then
execute.
Lucky for me too, since what I saw fit was already wrong twice on this
elevation issue...
> That would help other users and us maintainers a lot. None of us has
> access to all possible environments/systems and can care for all border
> cases. Or take the next step and be a maintainer yourself. In most
> cases it's not as much work in the long run as you think it is in the
> beginning (when creating your package(s) the first time).
I'm probably not maintainer material. I don't care to discuss it on this
list, but it has nothing to do with the mechanics of maintaining a
package. If you'd like to discuss it or convince me otherwise, you may
contact me personally.
> Talking about Vista migration. From Cygwin's point of view Vista
> is just another OS. The user is just another user. Either the user
> has certain privileges or not. A function works or returns EACCES.
> That's all. Elevation is not an issue for Cygwin, for pretty dumb
> technical reasons.
Though it is an issue from the cygwin user's point of view.
But I do understand where you are coming from. Microsoft also took the
same approach (nothing was done to ease the pain of using Windows command
line tools requiring elevation). Not that that necessarily makes it
http://acronyms.thefreedictionary.com/TRTTD ...
> The only concession *I* would be willing to make
> (but that's just me) is to add some text to admin scripts along these
> lines:
>
> *** Alarm! I couldn't create file foo.
> *** You're missing privileges. If you're admin user and running
> *** on Vista, did you think to run the script in an elevated shell?
That's actually decently close to what I was asking about. Though the
error statement could be qualified with (onVista && !elevated), and some
scripts which don't make sense without elevation (e.g. ssh-host-config)
could just test for that right from the get-go. Plus there's no reason
that compiled commands couldn't do something similar (e.g. "regtool add").
Any code requiring elevation is obviously already cygwin specific.
But, it sounds to me like that is not worth doing and/or not desirable.
That's a perfectly good answer. And I'm fine with that, believe me. An
answer is all I was looking for.
So, to summarize this thread and move on:
1) vista specific documentation is welcome
2) patches to csih/ssh-host-config for 1.7+vista+domain users are welcome
3) patches for elevation issues are not
I'm willing to take a whack at 1), so if anyone has any specific topics
that should be covered or any hints on where this documentation belongs,
please let me know. Else, I'll just do as I see fit.
I sould also like to address 2), but I am now in the boat of not having
access to the required environments/systems. So I can't commit to that
one.
Herb.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: sshd on vista error "initgroups: Permission denied" (cygwin-1.7)
2008-11-20 23:41 ` Herb Maeder
2008-11-20 23:53 ` Herb Maeder
@ 2008-11-21 0:18 ` Matthew Woehlke
2008-11-21 0:49 ` Herb Maeder
` (5 subsequent siblings)
7 siblings, 0 replies; 77+ messages in thread
From: Matthew Woehlke @ 2008-11-21 0:18 UTC (permalink / raw)
To: cygwin
Herb Maeder wrote:
> Any code requiring elevation is obviously already cygwin specific.
How so? There are tools on Linux that are only useful if run as root;
how is that significantly different? (Especially on SELinux systems
where rights are much more complicated than in the traditional UNIX model.)
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
C++ is for people who want to be able to not just shoot themselves in
the foot, but do it with a rocket launcher. -- Igor Peshansky
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: sshd on vista error "initgroups: Permission denied" (cygwin-1.7)
2008-11-20 23:41 ` Herb Maeder
2008-11-20 23:53 ` Herb Maeder
2008-11-21 0:18 ` Matthew Woehlke
@ 2008-11-21 0:49 ` Herb Maeder
2008-11-21 3:09 ` Herb Maeder
` (4 subsequent siblings)
7 siblings, 0 replies; 77+ messages in thread
From: Herb Maeder @ 2008-11-21 0:49 UTC (permalink / raw)
To: cygwin
On 20 Nov 2008 11:37:23 +0100, Corinna Vinschen wrote:
> > Note, I'm not requesting any changes. I'm just trying to understand if we
> > could/should establish guidelines for admin tasks requiring elevation.
>
> All nice points but I don't think that you have to convince anybody that
> better documentation and scripts which work better in any environment
> are preferrable. The point is, http://cygwin.com/acronyms/#SHTDI
> We can discuss stuff like that at great length but it won't help
> anybody if the docs and code doesn't get fixed along these lines.
OTOH, if you can't discuss stuff before patching, you're more likely to
get garbage. Witness the last guy who tried.
> Be a part of the project and suggest documentation patches as you see
> fit, or create code patches for scripts to make them more intelligent.
Um, that's what I was trying to do. It just that I'm not a big fan of the
"patch first, discuss later" philosophy, especially when I'm in unfamiliar
territory. I usually try to get agreement on a gameplan first, then
execute.
Lucky for me too, since what I saw fit was already wrong twice on this
elevation issue...
> That would help other users and us maintainers a lot. None of us has
> access to all possible environments/systems and can care for all border
> cases. Or take the next step and be a maintainer yourself. In most
> cases it's not as much work in the long run as you think it is in the
> beginning (when creating your package(s) the first time).
I'm probably not maintainer material. I don't care to discuss it on this
list, but it has nothing to do with the mechanics of maintaining a
package. If you'd like to discuss it or convince me otherwise, you may
contact me personally.
> Talking about Vista migration. From Cygwin's point of view Vista
> is just another OS. The user is just another user. Either the user
> has certain privileges or not. A function works or returns EACCES.
> That's all. Elevation is not an issue for Cygwin, for pretty dumb
> technical reasons.
Though it is an issue from the cygwin user's point of view.
But I do understand where you are coming from. Microsoft also took the
same approach (nothing was done to ease the pain of using Windows command
line tools requiring elevation). Not that that necessarily makes it
http://acronyms.thefreedictionary.com/TRTTD ...
> The only concession *I* would be willing to make
> (but that's just me) is to add some text to admin scripts along these
> lines:
>
> *** Alarm! I couldn't create file foo.
> *** You're missing privileges. If you're admin user and running
> *** on Vista, did you think to run the script in an elevated shell?
That's actually decently close to what I was asking about. Though the
error statement could be qualified with (onVista && !elevated), and some
scripts which don't make sense without elevation (e.g. ssh-host-config)
could just test for that right from the get-go. Plus there's no reason
that compiled commands couldn't do something similar (e.g. "regtool add").
Any code requiring elevation is obviously already cygwin specific.
But, it sounds to me like that is not worth doing and/or not desirable.
That's a perfectly good answer. And I'm fine with that, believe me. An
answer is all I was looking for.
So, to summarize this thread and move on:
1) vista specific documentation is welcome
2) patches to csih/ssh-host-config for 1.7+vista+domain users are welcome
3) patches for elevation issues are not
I'm willing to take a whack at 1), so if anyone has any specific topics
that should be covered or any hints on where this documentation belongs,
please let me know. Else, I'll just do as I see fit.
I sould also like to address 2), but I am now in the boat of not having
access to the required environments/systems. So I can't commit to that
one.
Herb.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: sshd on vista error "initgroups: Permission denied" (cygwin-1.7)
2008-11-20 23:41 ` Herb Maeder
` (2 preceding siblings ...)
2008-11-21 0:49 ` Herb Maeder
@ 2008-11-21 3:09 ` Herb Maeder
2008-11-21 7:05 ` Herb Maeder
` (3 subsequent siblings)
7 siblings, 0 replies; 77+ messages in thread
From: Herb Maeder @ 2008-11-21 3:09 UTC (permalink / raw)
To: cygwin
On 20 Nov 2008 11:37:23 +0100, Corinna Vinschen wrote:
> > Note, I'm not requesting any changes. I'm just trying to understand if we
> > could/should establish guidelines for admin tasks requiring elevation.
>
> All nice points but I don't think that you have to convince anybody that
> better documentation and scripts which work better in any environment
> are preferrable. The point is, http://cygwin.com/acronyms/#SHTDI
> We can discuss stuff like that at great length but it won't help
> anybody if the docs and code doesn't get fixed along these lines.
OTOH, if you can't discuss stuff before patching, you're more likely to
get garbage. Witness the last guy who tried.
> Be a part of the project and suggest documentation patches as you see
> fit, or create code patches for scripts to make them more intelligent.
Um, that's what I was trying to do. It just that I'm not a big fan of the
"patch first, discuss later" philosophy, especially when I'm in unfamiliar
territory. I usually try to get agreement on a gameplan first, then
execute.
Lucky for me too, since what I saw fit was already wrong twice on this
elevation issue...
> That would help other users and us maintainers a lot. None of us has
> access to all possible environments/systems and can care for all border
> cases. Or take the next step and be a maintainer yourself. In most
> cases it's not as much work in the long run as you think it is in the
> beginning (when creating your package(s) the first time).
I'm probably not maintainer material. I don't care to discuss it on this
list, but it has nothing to do with the mechanics of maintaining a
package. If you'd like to discuss it or convince me otherwise, you may
contact me personally.
> Talking about Vista migration. From Cygwin's point of view Vista
> is just another OS. The user is just another user. Either the user
> has certain privileges or not. A function works or returns EACCES.
> That's all. Elevation is not an issue for Cygwin, for pretty dumb
> technical reasons.
Though it is an issue from the cygwin user's point of view.
But I do understand where you are coming from. Microsoft also took the
same approach (nothing was done to ease the pain of using Windows command
line tools requiring elevation). Not that that necessarily makes it
http://acronyms.thefreedictionary.com/TRTTD ...
> The only concession *I* would be willing to make
> (but that's just me) is to add some text to admin scripts along these
> lines:
>
> *** Alarm! I couldn't create file foo.
> *** You're missing privileges. If you're admin user and running
> *** on Vista, did you think to run the script in an elevated shell?
That's actually decently close to what I was asking about. Though the
error statement could be qualified with (onVista && !elevated), and some
scripts which don't make sense without elevation (e.g. ssh-host-config)
could just test for that right from the get-go. Plus there's no reason
that compiled commands couldn't do something similar (e.g. "regtool add").
Any code requiring elevation is obviously already cygwin specific.
But, it sounds to me like that is not worth doing and/or not desirable.
That's a perfectly good answer. And I'm fine with that, believe me. An
answer is all I was looking for.
So, to summarize this thread and move on:
1) vista specific documentation is welcome
2) patches to csih/ssh-host-config for 1.7+vista+domain users are welcome
3) patches for elevation issues are not
I'm willing to take a whack at 1), so if anyone has any specific topics
that should be covered or any hints on where this documentation belongs,
please let me know. Else, I'll just do as I see fit.
I sould also like to address 2), but I am now in the boat of not having
access to the required environments/systems. So I can't commit to that
one.
Herb.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: sshd on vista error "initgroups: Permission denied" (cygwin-1.7)
2008-11-20 23:41 ` Herb Maeder
` (3 preceding siblings ...)
2008-11-21 3:09 ` Herb Maeder
@ 2008-11-21 7:05 ` Herb Maeder
2008-11-21 11:40 ` Herb Maeder
` (2 subsequent siblings)
7 siblings, 0 replies; 77+ messages in thread
From: Herb Maeder @ 2008-11-21 7:05 UTC (permalink / raw)
To: cygwin
On 20 Nov 2008 11:37:23 +0100, Corinna Vinschen wrote:
> > Note, I'm not requesting any changes. I'm just trying to understand if we
> > could/should establish guidelines for admin tasks requiring elevation.
>
> All nice points but I don't think that you have to convince anybody that
> better documentation and scripts which work better in any environment
> are preferrable. The point is, http://cygwin.com/acronyms/#SHTDI
> We can discuss stuff like that at great length but it won't help
> anybody if the docs and code doesn't get fixed along these lines.
OTOH, if you can't discuss stuff before patching, you're more likely to
get garbage. Witness the last guy who tried.
> Be a part of the project and suggest documentation patches as you see
> fit, or create code patches for scripts to make them more intelligent.
Um, that's what I was trying to do. It just that I'm not a big fan of the
"patch first, discuss later" philosophy, especially when I'm in unfamiliar
territory. I usually try to get agreement on a gameplan first, then
execute.
Lucky for me too, since what I saw fit was already wrong twice on this
elevation issue...
> That would help other users and us maintainers a lot. None of us has
> access to all possible environments/systems and can care for all border
> cases. Or take the next step and be a maintainer yourself. In most
> cases it's not as much work in the long run as you think it is in the
> beginning (when creating your package(s) the first time).
I'm probably not maintainer material. I don't care to discuss it on this
list, but it has nothing to do with the mechanics of maintaining a
package. If you'd like to discuss it or convince me otherwise, you may
contact me personally.
> Talking about Vista migration. From Cygwin's point of view Vista
> is just another OS. The user is just another user. Either the user
> has certain privileges or not. A function works or returns EACCES.
> That's all. Elevation is not an issue for Cygwin, for pretty dumb
> technical reasons.
Though it is an issue from the cygwin user's point of view.
But I do understand where you are coming from. Microsoft also took the
same approach (nothing was done to ease the pain of using Windows command
line tools requiring elevation). Not that that necessarily makes it
http://acronyms.thefreedictionary.com/TRTTD ...
> The only concession *I* would be willing to make
> (but that's just me) is to add some text to admin scripts along these
> lines:
>
> *** Alarm! I couldn't create file foo.
> *** You're missing privileges. If you're admin user and running
> *** on Vista, did you think to run the script in an elevated shell?
That's actually decently close to what I was asking about. Though the
error statement could be qualified with (onVista && !elevated), and some
scripts which don't make sense without elevation (e.g. ssh-host-config)
could just test for that right from the get-go. Plus there's no reason
that compiled commands couldn't do something similar (e.g. "regtool add").
Any code requiring elevation is obviously already cygwin specific.
But, it sounds to me like that is not worth doing and/or not desirable.
That's a perfectly good answer. And I'm fine with that, believe me. An
answer is all I was looking for.
So, to summarize this thread and move on:
1) vista specific documentation is welcome
2) patches to csih/ssh-host-config for 1.7+vista+domain users are welcome
3) patches for elevation issues are not
I'm willing to take a whack at 1), so if anyone has any specific topics
that should be covered or any hints on where this documentation belongs,
please let me know. Else, I'll just do as I see fit.
I sould also like to address 2), but I am now in the boat of not having
access to the required environments/systems. So I can't commit to that
one.
Herb.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: sshd on vista error "initgroups: Permission denied" (cygwin-1.7)
2008-11-20 23:41 ` Herb Maeder
` (4 preceding siblings ...)
2008-11-21 7:05 ` Herb Maeder
@ 2008-11-21 11:40 ` Herb Maeder
2008-11-21 13:48 ` Herb Maeder
2008-11-21 14:46 ` Herb Maeder
7 siblings, 0 replies; 77+ messages in thread
From: Herb Maeder @ 2008-11-21 11:40 UTC (permalink / raw)
To: cygwin
On 20 Nov 2008 11:37:23 +0100, Corinna Vinschen wrote:
> > Note, I'm not requesting any changes. I'm just trying to understand if we
> > could/should establish guidelines for admin tasks requiring elevation.
>
> All nice points but I don't think that you have to convince anybody that
> better documentation and scripts which work better in any environment
> are preferrable. The point is, http://cygwin.com/acronyms/#SHTDI
> We can discuss stuff like that at great length but it won't help
> anybody if the docs and code doesn't get fixed along these lines.
OTOH, if you can't discuss stuff before patching, you're more likely to
get garbage. Witness the last guy who tried.
> Be a part of the project and suggest documentation patches as you see
> fit, or create code patches for scripts to make them more intelligent.
Um, that's what I was trying to do. It just that I'm not a big fan of the
"patch first, discuss later" philosophy, especially when I'm in unfamiliar
territory. I usually try to get agreement on a gameplan first, then
execute.
Lucky for me too, since what I saw fit was already wrong twice on this
elevation issue...
> That would help other users and us maintainers a lot. None of us has
> access to all possible environments/systems and can care for all border
> cases. Or take the next step and be a maintainer yourself. In most
> cases it's not as much work in the long run as you think it is in the
> beginning (when creating your package(s) the first time).
I'm probably not maintainer material. I don't care to discuss it on this
list, but it has nothing to do with the mechanics of maintaining a
package. If you'd like to discuss it or convince me otherwise, you may
contact me personally.
> Talking about Vista migration. From Cygwin's point of view Vista
> is just another OS. The user is just another user. Either the user
> has certain privileges or not. A function works or returns EACCES.
> That's all. Elevation is not an issue for Cygwin, for pretty dumb
> technical reasons.
Though it is an issue from the cygwin user's point of view.
But I do understand where you are coming from. Microsoft also took the
same approach (nothing was done to ease the pain of using Windows command
line tools requiring elevation). Not that that necessarily makes it
http://acronyms.thefreedictionary.com/TRTTD ...
> The only concession *I* would be willing to make
> (but that's just me) is to add some text to admin scripts along these
> lines:
>
> *** Alarm! I couldn't create file foo.
> *** You're missing privileges. If you're admin user and running
> *** on Vista, did you think to run the script in an elevated shell?
That's actually decently close to what I was asking about. Though the
error statement could be qualified with (onVista && !elevated), and some
scripts which don't make sense without elevation (e.g. ssh-host-config)
could just test for that right from the get-go. Plus there's no reason
that compiled commands couldn't do something similar (e.g. "regtool add").
Any code requiring elevation is obviously already cygwin specific.
But, it sounds to me like that is not worth doing and/or not desirable.
That's a perfectly good answer. And I'm fine with that, believe me. An
answer is all I was looking for.
So, to summarize this thread and move on:
1) vista specific documentation is welcome
2) patches to csih/ssh-host-config for 1.7+vista+domain users are welcome
3) patches for elevation issues are not
I'm willing to take a whack at 1), so if anyone has any specific topics
that should be covered or any hints on where this documentation belongs,
please let me know. Else, I'll just do as I see fit.
I sould also like to address 2), but I am now in the boat of not having
access to the required environments/systems. So I can't commit to that
one.
Herb.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: sshd on vista error "initgroups: Permission denied" (cygwin-1.7)
2008-11-20 23:41 ` Herb Maeder
` (5 preceding siblings ...)
2008-11-21 11:40 ` Herb Maeder
@ 2008-11-21 13:48 ` Herb Maeder
2008-11-21 14:46 ` Herb Maeder
7 siblings, 0 replies; 77+ messages in thread
From: Herb Maeder @ 2008-11-21 13:48 UTC (permalink / raw)
To: cygwin
On 20 Nov 2008 11:37:23 +0100, Corinna Vinschen wrote:
> > Note, I'm not requesting any changes. I'm just trying to understand if we
> > could/should establish guidelines for admin tasks requiring elevation.
>
> All nice points but I don't think that you have to convince anybody that
> better documentation and scripts which work better in any environment
> are preferrable. The point is, http://cygwin.com/acronyms/#SHTDI
> We can discuss stuff like that at great length but it won't help
> anybody if the docs and code doesn't get fixed along these lines.
OTOH, if you can't discuss stuff before patching, you're more likely to
get garbage. Witness the last guy who tried.
> Be a part of the project and suggest documentation patches as you see
> fit, or create code patches for scripts to make them more intelligent.
Um, that's what I was trying to do. It just that I'm not a big fan of the
"patch first, discuss later" philosophy, especially when I'm in unfamiliar
territory. I usually try to get agreement on a gameplan first, then
execute.
Lucky for me too, since what I saw fit was already wrong twice on this
elevation issue...
> That would help other users and us maintainers a lot. None of us has
> access to all possible environments/systems and can care for all border
> cases. Or take the next step and be a maintainer yourself. In most
> cases it's not as much work in the long run as you think it is in the
> beginning (when creating your package(s) the first time).
I'm probably not maintainer material. I don't care to discuss it on this
list, but it has nothing to do with the mechanics of maintaining a
package. If you'd like to discuss it or convince me otherwise, you may
contact me personally.
> Talking about Vista migration. From Cygwin's point of view Vista
> is just another OS. The user is just another user. Either the user
> has certain privileges or not. A function works or returns EACCES.
> That's all. Elevation is not an issue for Cygwin, for pretty dumb
> technical reasons.
Though it is an issue from the cygwin user's point of view.
But I do understand where you are coming from. Microsoft also took the
same approach (nothing was done to ease the pain of using Windows command
line tools requiring elevation). Not that that necessarily makes it
http://acronyms.thefreedictionary.com/TRTTD ...
> The only concession *I* would be willing to make
> (but that's just me) is to add some text to admin scripts along these
> lines:
>
> *** Alarm! I couldn't create file foo.
> *** You're missing privileges. If you're admin user and running
> *** on Vista, did you think to run the script in an elevated shell?
That's actually decently close to what I was asking about. Though the
error statement could be qualified with (onVista && !elevated), and some
scripts which don't make sense without elevation (e.g. ssh-host-config)
could just test for that right from the get-go. Plus there's no reason
that compiled commands couldn't do something similar (e.g. "regtool add").
Any code requiring elevation is obviously already cygwin specific.
But, it sounds to me like that is not worth doing and/or not desirable.
That's a perfectly good answer. And I'm fine with that, believe me. An
answer is all I was looking for.
So, to summarize this thread and move on:
1) vista specific documentation is welcome
2) patches to csih/ssh-host-config for 1.7+vista+domain users are welcome
3) patches for elevation issues are not
I'm willing to take a whack at 1), so if anyone has any specific topics
that should be covered or any hints on where this documentation belongs,
please let me know. Else, I'll just do as I see fit.
I sould also like to address 2), but I am now in the boat of not having
access to the required environments/systems. So I can't commit to that
one.
Herb.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: sshd on vista error "initgroups: Permission denied" (cygwin-1.7)
2008-11-20 23:41 ` Herb Maeder
` (6 preceding siblings ...)
2008-11-21 13:48 ` Herb Maeder
@ 2008-11-21 14:46 ` Herb Maeder
7 siblings, 0 replies; 77+ messages in thread
From: Herb Maeder @ 2008-11-21 14:46 UTC (permalink / raw)
To: cygwin
On 20 Nov 2008 11:37:23 +0100, Corinna Vinschen wrote:
> > Note, I'm not requesting any changes. I'm just trying to understand if we
> > could/should establish guidelines for admin tasks requiring elevation.
>
> All nice points but I don't think that you have to convince anybody that
> better documentation and scripts which work better in any environment
> are preferrable. The point is, http://cygwin.com/acronyms/#SHTDI
> We can discuss stuff like that at great length but it won't help
> anybody if the docs and code doesn't get fixed along these lines.
OTOH, if you can't discuss stuff before patching, you're more likely to
get garbage. Witness the last guy who tried.
> Be a part of the project and suggest documentation patches as you see
> fit, or create code patches for scripts to make them more intelligent.
Um, that's what I was trying to do. It just that I'm not a big fan of the
"patch first, discuss later" philosophy, especially when I'm in unfamiliar
territory. I usually try to get agreement on a gameplan first, then
execute.
Lucky for me too, since what I saw fit was already wrong twice on this
elevation issue...
> That would help other users and us maintainers a lot. None of us has
> access to all possible environments/systems and can care for all border
> cases. Or take the next step and be a maintainer yourself. In most
> cases it's not as much work in the long run as you think it is in the
> beginning (when creating your package(s) the first time).
I'm probably not maintainer material. I don't care to discuss it on this
list, but it has nothing to do with the mechanics of maintaining a
package. If you'd like to discuss it or convince me otherwise, you may
contact me personally.
> Talking about Vista migration. From Cygwin's point of view Vista
> is just another OS. The user is just another user. Either the user
> has certain privileges or not. A function works or returns EACCES.
> That's all. Elevation is not an issue for Cygwin, for pretty dumb
> technical reasons.
Though it is an issue from the cygwin user's point of view.
But I do understand where you are coming from. Microsoft also took the
same approach (nothing was done to ease the pain of using Windows command
line tools requiring elevation). Not that that necessarily makes it
http://acronyms.thefreedictionary.com/TRTTD ...
> The only concession *I* would be willing to make
> (but that's just me) is to add some text to admin scripts along these
> lines:
>
> *** Alarm! I couldn't create file foo.
> *** You're missing privileges. If you're admin user and running
> *** on Vista, did you think to run the script in an elevated shell?
That's actually decently close to what I was asking about. Though the
error statement could be qualified with (onVista && !elevated), and some
scripts which don't make sense without elevation (e.g. ssh-host-config)
could just test for that right from the get-go. Plus there's no reason
that compiled commands couldn't do something similar (e.g. "regtool add").
Any code requiring elevation is obviously already cygwin specific.
But, it sounds to me like that is not worth doing and/or not desirable.
That's a perfectly good answer. And I'm fine with that, believe me. An
answer is all I was looking for.
So, to summarize this thread and move on:
1) vista specific documentation is welcome
2) patches to csih/ssh-host-config for 1.7+vista+domain users are welcome
3) patches for elevation issues are not
I'm willing to take a whack at 1), so if anyone has any specific topics
that should be covered or any hints on where this documentation belongs,
please let me know. Else, I'll just do as I see fit.
I sould also like to address 2), but I am now in the boat of not having
access to the required environments/systems. So I can't commit to that
one.
Herb.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Does CYGWIN work on Windows 2008 x86 architecture ?
[not found] ` <corinna-cygwin@cygwin.com>
` (17 preceding siblings ...)
2008-11-20 23:41 ` Herb Maeder
@ 2009-02-16 16:16 ` Freddy Jensen
18 siblings, 0 replies; 77+ messages in thread
From: Freddy Jensen @ 2009-02-16 16:16 UTC (permalink / raw)
To: cygwin; +Cc: jensen
>From: Corinna Vinschen <corinna-cygwin@cygwin.com>
>Date: Mon Feb 16 2009 3:07am
>To: "cygwin@cygwin.com" <cygwin@cygwin.com>
>Subj: Re: Does CYGWIN work on Windows 2008 x86 architecture ?
>
>On Feb 16 11:05, Martine Carannante wrote:
>> Hi
>>
>> I try again to ask if someone has installed CYGWIN on Windows 2008 x86
>> architecture.
>>
>> It works fine on x64 architecture but bash fails on X86 like this
>> bash
>> 2 [main] bash 3520 _cygtls::handle_exceptions: Exception:
>> STATUS_ACCESS_VIOLATION
>> 315 [main] bash 3520 open_stackdumpfile: Dumping stack trace to
>> bash.exe.stackdump
>> 430671 [main] bash 3520 _cygtls::handle_exceptions: Exception:
>> STATUS_ACCESS_VIOLATION
>> 448747 [main] bash 3520 _cygtls::handle_exceptions: Error while dumping
>> state (
>> probably corrupted stack)
>>
>> I have not found an answer in the cygwin mailing list.
>
>Works fine for me. Except in one case:
>http://cygwin.com/ml/cygwin/2008-10/msg00459.html
>
>I opened a support case at Microsoft but it has been refused.
>
>Since the problem occurs in a Microsoft DLL, we have no way to fix it
>in Cygwin. Cygwin 1.7 has a crude workaround for this situation,
>though. So your choices are
>
>- Deinstall Terminal Services entirely
>- Switch off DEP
>- Use Cygwin 1.7 (still in TEST for another few weeks)
>
>If it's not TS, it's probably a case of
>http://cygwin.com/acronyms/#BLODA
>
>Corinna
>
>--
>Corinna Vinschen Please, send mails regarding Cygwin to
>Cygwin Project Co-Leader cygwin AT cygwin DOT com
>Red Hat
>
For me it works with pre-1.7 versions of cygwin as long as I have
switched off DEP and uninstallled Terminal Services.
I think the problem is independent of whether it is x86 or x64 because
for me the problem occurs on x64.
Thanks
Freddy
--
Freddy Jensen, Sr. Computer Scientist, Adobe Systems Incorporated
345 Park Avenue, San Jose, CA 95110-2704, USA, Ph: (408) 536-2869
Email: jensen@adobe.com, URL: http://www.adobe.com
--
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 77+ messages in thread