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/
