This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: sshd on vista error "initgroups: Permission denied" (cygwin-1.7)

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,
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

   *** 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 Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]