Looks like the permissions have changed since 2003 SP1; "Service Control Manager Security for non-admins" has more information and a fix that allows authenticated users the ability to list services.
I'm playing around with the "sc sdshow" and "sc sdset" commands to give me the ability to control the cygwin sshd service on a win7 home from my unbuntu machine. The first sdset command in that article gave me the ability to list some services from linux, so it shows promise.
I'll try to post back with more detailed instructions, but that should be enough to get you started. Good luck.
OK; so here's what I did and it seems to do the trick. Note that you have to run these commands in an elevated "cmd.exe" - search the start bubble for "cmd", right click, run as administrator.
First, get the current security descriptor for the service control manager:
sc sdshow scmanager
This gave me almost exactly as listed in the link above. The form of the output is
D:(DACL)(DACL)(...)S:(SACL)(SACL)(...). Each DACL is structured as a
;-delimited string. The first, third, and last fields are the important parts. The first is
A for "allow" and
D for "deny". The last part is either an abbreviation for a well known user or group, or it is the SID of a user or group. The third string is a series of permissions - one permission per pair of characters. The full breakdown is at "MSDN Article: ACE Strings". The meaning of the characters in the "rights" field is a bit difference for the service control manager, and different again for services. If you cross reference the three tables from that first link you will see what I mean. So for example,
(A;;CC;;;AU) as given by the
sc sdshow scmanager command means that authenticated users are allowed to connect to the service control manager. The article recommends expanding that to
(A;;CCLCRPRC;;;AU) which is "CC", "LC", "RP", and "RC" - "connect", "enumerate", "query lock status", and "read control". Basically we are just giving "AU" - "Authenticated Users" the same rights as "IU" - "Interactive Users" - those users who are logged into Windows. When you change the DACL with 'sc sdset', you are replacing the entire entry, so you need to modify only the DACL that is important for your purposes, and copy the others.
sc sdset "D:(A;;CCLCRPRC;;;AU)(A;;CCLCRPRC;;;IU)(A;;CCLCRPRC;;;SU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;BA)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)"
Notice how I just replaced the DACL pertaining to "Authenticated Users".
OK; now for the easy part. For this you'll need "subinacl" - if you don't have it you can download it from the various Microsoft sites. (You could use 'sc sdset' but 'subinacl' is much easier. Unfortunately 'subinacl' only works with actual services, not the service control manager, hence the first step.) Personally I deviated from the article a bit and instead of granting my user permissions on the service, I created a local group, and added myself to that.
net localgroup "Service Operator" /add
net localgroup "Service Operator" "My Login Account" /add
Next, I gave that group full control over the sshd service:
subinacl /service sshd "/grant=Service Operator=F"
On my linux machine, I can now start and stop the service:
$ net -S diabolique rpc service stop sshd
Enter beltorak's password:
sshd service is stopped.
$ net -S diabolique rpc service start sshd
Enter beltorak's password:
Failed to start service: sshd [WERR_OK]
I don't know why it says "failed: WERR_OK" - I think that's the equivalent of an error dialogue that says "ERROR: Success". Verifying the state of the service on the win7 machine definitely indicates that I can now control the service from my linux machine.
NOTE: It would probably be wise to grant the Service Operator group those extra permissions over the service control manager - I'm sure the restriction of rights for "authenticated users" was done for a reason - and to limit the permissions on sshd to just those required to start and stop the service. I was just happy to get it working, and this is a home network, so I'm done.