This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: CSIH patch (Re: Unable to run sshd under a domain sshd_server account [SOLVED])
- From: Charles Wilson <cygwin at cwilson dot fastmail dot fm>
- To: cygwin at cygwin dot com
- Date: Mon, 04 Aug 2008 21:31:32 -0400
- Subject: Re: CSIH patch (Re: Unable to run sshd under a domain sshd_server account [SOLVED])
- References: <3B3EFBD49B94AD4DBB7B7097257A8046DD020D@FDSVAST06SXCH01.flooddata.net> <Pine.GSO.4.63.0805121820090.11953@access1.cims.nyu.edu> <20080513073720.GA22193@calimero.vinschen.de> <3B3EFBD49B94AD4DBB7B7097257A8046DD02FC@FDSVAST06SXCH01.flooddata.net> <20080616210105.GI731@calimero.vinschen.de> <20080616211352.GK731@calimero.vinschen.de> <48821B9F.6070907@cwilson.fastmail.fm> <20080719171235.GO5675@calimero.vinschen.de> <488252B5.8000501@cwilson.fastmail.fm> <20080720122754.GP5675@calimero.vinschen.de> <20080720134054.GQ5675@calimero.vinschen.de>
Corinna Vinschen wrote:
Along these lines, yes. I also think that using the cyg_server/
cron_server/sshd_server account should be preferred over SYSTEM on XP
and earlier systems, at least if they are domain member machines. Maybe
simply like this: The test should run on any OS, but if none of the
accounts exists, the fallback for XP and earlier is SYSTEM. IIUC, that's
not quite what $csih_FORCE_PRIVILEGED_USER is for. Yes? No?
Correct -- csih_FORCE_PRIVILEGED_USER means FORCE; you're asking for a
gentle default behavior.
I've modified the behavior on NT/2k/XP when not
$csih_FORCE_PRIVILEGED_USER, so that if a 'known' privileged user
exists, then it is used. Otherwise, SYSTEM; no new users will be created.
However, on NT/2k/XP the $csih_FORCE_PRIVILEGED_USER behavior is
unchagned: if a privileged user already exists it will be used (as
above) -- but if one does NOT exist, one will be created and used. And
failure to create it is a script failure.
I tried the above script change on a XP domain member machine and
with csih_FORCE_PRIVILEGED_USER set to yes. It works, it's just a
bit bumpy:
*** Info: This script plans to use 'cyg_server'.
*** Info: 'cyg_server' will not be able to log on interactively, but will only
*** Info: be used by registered services.
The message is incorrect.
Fixed.
*** Query: Do you want to use different name? (yes/no) no
mkpasswd (273): [2221] The user name could not be found.
I'm not sure why is mkpasswd is called here, but it's called with -l
only so it can't find the domain account. Can this test be skipped
if the user has been directly taken from /etc/passwd?
Well, I *think* it is now skipped because that code path doesn't get
activated now, if the user was found (in /etc/passwd OR in localSAM).
Now, you only hit that line if you just created the user: which only
happens if it existed neither in the SAM nor in /etc/passwd. And, since
you just created it -- locally -- it obviously exists in the SAM /now/
-- but not yet in /etc/passwd. How do you add an entry to /etc/passwd
for a user in the local SAM? mkpasswd -l.
I added some comments at the appropriate places to make this clearer.
Btw., there's a test for the administrators group in /etc/passwd.
This test is not necessary. The only reason to have the admins
group in /etc/passwd is to print file ownership correctly. It doesn't
have any other value.
I don't see this. I see testing /etc/passwd for the (local)
Administrator USER, and testing /etc/group for the Administrators GROUP,
but not /etc/passwd <-> Administrators GROUP.
More info please?
Please try current CVS:
http://cygwin.com/cgi-bin/cvsweb.cgi/~checkout~/csih/cygwin-service-installation-helper.sh?rev=1.10&cvsroot=cygwin-apps
or
http://tinyurl.com/5ex7bl
--
Chuck
--
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/