Dave, Thanks for your comments. Unfortunately, rsh is not an option, thus
my desire for --execute. Rsh is not allowed through my firewalls into the
dmz's where many of my targets live. A dist daemon in the dmz, reachable by
internal distribution hubs only, is acceptable. If rsync can not handle the
-execute channel, I will have to build another service on another port
instead of using the existing rsync connection. OpenDeploy is the only
other tool I know of which offers this feature.
Judging by the response, I guess there is not much interest in building
--execute or maintaining it in the rsync daemon.
--Henry
-----Original Message-----
From: Dave Dykstra [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 13, 2001 10:38 AM
To: Wrieth, Henry
Cc: '[EMAIL PROTECTED]'; Menghani, Mahesh; Wieneke, Myron; Ayres,
Matt
Subject: Re: --execute option
On Mon, Feb 12, 2001 at 02:37:44PM -0500, Wrieth, Henry wrote:
> Regarding the secrets file:
> All hosts I distribute to are either internal or in some DMZ. In most
Wall
> Street firms the internal network is deemed safe so, it is still ok to
have
> clear passwords on the wire. We telnet everywhere. But it is deemed
risky
> to have clear passwords on the filesystems. Local sys admins would have
> access to passwords which may be used across different domains. Shelves
> full of broken drives could be read, whatever, it is just not allowed.
> In situations where the network is insecure and the server is secure, I
> agree, it makes more sense to do it your way. All I am recommending is
we
> add an alternative.
In that case why not use rsh?
Alternatively, if you want to use passwords maybe rexec is what you need.
Most Unix machines have an rexec server and an rexec(3) library call to
invoke it but not all systems have a command level tool to use it (Linux
does although I believe I heard it may be removed in the most recent
releases).
> Regarding chroot:
> It seems there is a big concern about giving up the default chroot nature
of
> the child process. I think this is because chroot is being used by rsync
to
> enforces module security rules as it does with regard to links. The
> conventional idea of chroot, as when you chroot a web or ftp server, is
to
> protect the host from a rogue daemon. If a daemon were compromised by a
> hacker and that hacker has now assumed the username of the daemon, the
> hacker will only be able to see files up to the chroot directory and will
> only have access to executables in the chroot tree. This way, when a
hacker
> becomes the server he will not be able to damage, say /etc or /usr and
will
> not be able to execute rm if it is not in the chroot tree. With this
sense
> of chrooting it would be more conventional to chroot the parent rsync
daemon
> not each child since the parent could be compromised too and is running as
> root.
The parent isn't doing hardly anything except forking children so its
vulnerability is very low.
> I still think it is ok to chroot the child by default. I'm just saying if
> we allow children to spawn as client usernames, the child has normal user
> permissions. We no longer need to rely on chroot to restrict say,
> linking. The OS already restricts it accordingly for that user. Of
course,
> we may still want to restrict any or all rules like linking in the server
> config, and we may still want to chroot the child, but now we are doing so
> for secondary protection and we move primary enforcement to the OS. The
> short of it is, I do not think we need to make any changes to the chroot
> functionality to implement --execute. It can be turned off. And I don't
> think we should let it side track this discussion.
>
> Regarding ssh alternative to --execute:
> Yes there are several reasons I would prefer --execute than ssh. First,
> without going into any details ssh will not be permissioned through my
> security infrastructure. second, even if ssh were an option I would still
> prefer to have both messaging and distributions happen over the same
> channel. This would avoid having two holes everywhere rather than one.
> third, I think it is much cleaner to make the execute part of the
deployment
> engine rather than part of the wrapper. If it weren't, I would still need
> another mechanism to do the remote execution. Since rsync already has a
> connection, why not use it.
Well we don't want to add functionality to rsync if it can be easily done
by another tool because the more functionality there is the more there is
to maintain.
Again, consider using rsh if you're not worried about the network but are
worried about passwords on the servers. Here's a trick that may help
you: when using rsh, the remote rsync target may be any arbitrary shell
command that returns a list of files or directories. I use this in one of
my
scripts:
rsync -a /srcdir/ remotehost:'`df -k . >&2;echo /destdir/`'
The output of df on the remote side sent to stderr and printed, and then it
copies to /destdir. This only works for pre-commands, but you could
probably
make a clever --rsh or --rsync-path command to do what you want.
- Dave Dykstra
This message is for the named person's use only. It may contain
confidential, proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission.
If you receive this message in error, please immediately delete it and all
copies of it from your system, destroy any hard copies of it and notify the
sender. You must not, directly or indirectly, use, disclose, distribute,
print, or copy any part of this message if you are not the intended
recipient. CREDIT SUISSE GROUP and each of its subsidiaries each reserve
the right to monitor all e-mail communications through its networks. Any
views expressed in this message are those of the individual sender, except
where the message states otherwise and the sender is authorised to state
them to be the views of any such entity.
Unless otherwise stated, any pricing information given in this message is
indicative only, is subject to change and does not constitute an offer to
deal at any price quoted.
Any reference to the terms of executed transactions should be treated as
preliminary only and subject to our formal written confirmation.
