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: /etc/group manual-edits-workaround still reqd in 1.7?


On Mon 7/28/08 10:18 +0200 Corinna Vinschen wrote:
> On Jul 26 09:12, Tom Rodman wrote:
> > I use cygwin in a large domain, from time to time my account is
> > added or removed from domain groups without any warning (last
> > time 'IT' added 'Domain Users' to some other domain group - so all
> > domain users were impacted!).  When this happens my credentials in
> > a password-authenticated ssh session, get clobbered & I have
> > to manually edit /etc/group, per:
> > 
> >   http://cygwin.com/ml/cygwin/2005-07/msg01287.html
> > 
> > Does this issue "go away" under cygwin 1.7?
> 
> I don't know but it's supposed to be better.  I relaxed the rules which
> result in a token created through password login being overridden with a
> self-created token.  

Thanks Corinna/appreciate your help.  

When that self-created token is created (under 1.5.x) is that
the point that cygwin looks for the user's group memberships
as defined in /etc/group?

> You will still have to create a new /etc/group, though.

Creating it daily (w/cron) is no problem, but, I'm still not
clear.. in 1.7 do we still have to (in addition) update /etc/group
so that domain users (that actually use ssh) have their comma
delimited usernames in the last field on the respective lines in
/etc/group, for all the domain groups they belong to?

I suppose .. to be fair- if cygwin needs to list all the domain
groups I'm in, then it should be able to determine this "in the
UNIX way", by looking at /etc/group.  The problem is that our
accts get added to groups by our IT dept w/o any advance warning.

some observations:

  In cygwin 1.5.x when domain user 'johndoe' starts a password
  authenticated ssh session on a host where the /etc/group file is
  complete ( ie has *all* the local and domain groups), but does
  NOT have the edits in place (where user 'johndoe' listed in
  all the domain groups within /etc/group that he belongs too), then this
  session will be "untrusted by network shares", even shares with read
  access to EVERYONE.  Within this type of deprecated session (on
  windows 2003 server), I've noticed:

     LOGNAME is set to     'sshd_server'
    USERNAME is set to     'sshd_server'
     output of 'id -un' is 'johndoe'

    "mkpasswd -d -u johndoe" fails w/:
      mkpasswd (272): [1326] Logon failure: unknown user name or bad password

    you get a 'Permission denied' error even when your just trying to read a
    share that has an "everyone READ" ace on the share and the directory

--
thanks/regards,
Tom

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


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