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: permission denied for NTFS network shares

I didn't manage to make "cygrunsrv -u ..." to work.
The service is installed but refuses to start.
Besides its quite a nuisance to add all those fancy priviledges to every user/computer that will use rsh.

The situation is like that:
I have interactive RSH that works fine and noninteractive rsh (using .rhosts) that denies access to network shares.
So I used "Expect" to pass a password and command to rsh (as Chris January have suggested), converting interactive RSH to noninteractive and keeping all the benefits.
Here is the "Expect" script that does a job (its actually modifed expect example from the WEB):

#! /bin/expect -f
# wrapper for RSH to make it non-interactive
# server name is passed as 1st arg, command as 2nd

set password DefaultPassword
set user DefaultUser
set server [lindex $argv 0]
set cmd [lindex $argv 1]
spawn rsh $server -l $user
expect "Password:"
send "$password\r"
expect '$'
send "$cmd\r"
expect eof

The drawback of this solution is that you must have a default domain user whose password is known to everybody (like the password of farm or lab computer).
The good part is that you don't need to play with permission on any computer. This wrapper will work plug and play on any computer where
"inetd" service is installed.

Best regards and thanks to everybody who tried to help

Genady Veytsman wrote

Are you saying that there is no way whatsoever to have RSH without
passwords? I need it for running scripts/programs on different NT
machines. Interactive behaviour (login/password) will not allow that
since you can't hardcode your passwords in scripts.
If you are the only user needing to rsh into the system
you could try to run the daemons under your own name
(cygrunsrv -u, read the README). You may also have to change
ownership of key files and such.
A more ambitious/risky project is to give privileges to create tokens
etc.. (see README) to a domain account and run the daemons under
that account.
I have not tried any of that, let us know if it works.


Unsubscribe info:
Bug reporting:

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