Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/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
Message-ID:	<3E730EBB.9080700@attglobal.net>
Date:	Sat, 15 Mar 2003 03:30:03 -0800
From:	Doug VanLeuven <roamdad AT attglobal DOT net>
User-Agent:	Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210
X-Accept-Language:	en-us, en
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: [ANNOUNCEMENT] New release of setup.exe (2.249.2.10)
References:	<20030313205847 DOT E1E4B1C221 AT redhat DOT com> <3E710A26 DOT 5050207 AT t-online DOT de> <20030314025249 DOT GB33739617 AT hpn5170x> <3E718AD8 DOT 4010209 AT t-online DOT de> <3E71E49E DOT 3D2F3ABF AT ieee DOT org> <3E720A5A DOT 9060804 AT t-online DOT de>
In-Reply-To:	<3E720A5A.9060804@t-online.de>
X-MailScanner:	Found to be clean

Markus Schönhaber wrote:
> Pierre A. Humblet wrote:
> 
>> Here is another point of concern: assume a non privileged domain user
>> runs setup and answers "yes" to the "Run as Administrator" dialog.
>> It is likely that no entry will be made for the domain user in 
>> /etc/passwd
>> To verify that it will be necessary to rename /etc/passwd  before
>> running setup.
>> Thanks for trying when you have a chance.
>>
> 
> Well, the account that is proposed by default by the Run As dialog ist 
> the local Administrator. Running under that account setup will alomost 
> certainly fail to create the domain relevant information in /etc/passwd 
> and /etc/group. But I will try and verify that next week.
> OTOH: I wouldn't worry too much about that. Put that in the FAQ. This 
> should make things clear to the domain user who does an installation 
> with local administrative rights.
> Any domain administrator logged on under a restricted account and 
> therefore using the Run As feature knows that it would be a gould idea 
> to switch to his domain admin account when doing things where domain 
> access is relevant or he shouldn't have been made domain administrator 
> in the first place.

I wish I had just one domain.  To set this up in a mutidomain
environment, I'm finding
I install as an administrator of one of the domains DOMAIN1
create local passwd & group files
	passwd.local & group.local
create domain passwd & group files:
	passwd.DOMAIN1 & group.DOMAIN1
Then log in as an admin in domain DOMAIN2
create domain passwd & group files:
	passwd.DOMAIN2 group.DOMAIN2
...
Then finally combine them all
	cat passwd.* | sort | uniq > passwd
The sort & uniq is to remove the extra local accounts thoughtfully
provided when generating the domain password files.

The problem is when a user logs on who is more recent than when the
passwd file was initially created and so doesn't exist in /etc/passwd.
The user may not have admin privilege to regenerate the entire domain
file, but could extract their own info and append it via a craftily
written /etc/profile that performed the regeneration when the user
doesn't exist.
No, I'm not going into the overhead to associate the proper
uid offset.

(mkpasswd -u $USERNAME -d $USERDOMAIN; cat passwd.*)|sort|uniq >passwd

Then, I can periodically ship out an updated passwd.DOMAIN file to
be included by logon scripts, without having to have personalized
passwd files that reflect each machine's differing local accounts.

I just wanted to put it out there that seperately maintained
passwd files for the domain(s) & local accounts and a final
merge offer some real advantages.

Regards,
Doug VanLeuven


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -