[ANNOUNCEMENT] New release of setup.exe (2.249.2.10)

[Doug VanLeuven]

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/