This is the mail archive of the 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: [ANNOUNCEMENT] New release of setup.exe (

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.

Doug VanLeuven

-- Unsubscribe info: Bug reporting: Documentation: FAQ:

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