limiting remote usage

Hello,

I have a server and several users who need to synchronize from the
server. The purpose of the sever is *only* to allow them to
synchronize their files; nothing else should be permitted.

There are two options for this: using the "remote shell" method or the
"socket" method. However, with both options, the users have too much
"freedom".

With the "remote shell" option, it means that users can connect to the
server and do other stuff other than syncrhonize files. For instance,
they can run programs there. I really need to limit the server to
synchronize files, nothing else. That's why I say that, in this
set-up, the "remote shell" with the users too much "freedom".

The "socket" method removes the previous type of freedom. However,
there are two things to solve:
1- user authentication. How to restrict malicious users to use it?

2- restrict operation. Depending on the user, I would like to restrict
the paths that he can synchronize; maybe restrict whether they can
update files from and to the client and the server, or only from the
server to the client (-force rootPath). Maybe this could be achieved
by having the unison profiles defined in the server, rather than in
the client (the server administrator would be the one defining the
unison profiles, and not the users)

What do you think?
Do you know how to achieve this set-up?

Deleting a local file while synchronizing

Hello! 
  I am a new user to this mailing list. I am trying following.

environment : Linux
two servers: remote server : server_a
local server: server_b

I logged in to server_b

I have following setup

server_a: /home/myName/test_dir (test_dir contains a tree)
server_b: /home/myName/          (nothing)

I synchronized these things using unison. I used following command

server_a:/> unison ssh://server_b//home/myName/test_dir /home/myName/

This worked fine. Later, I added a file to server_b database

(i.e. file a.txt was added at (server_b)/home/myName/test_dir

I used the above command again. This time, unison deleted the file 
from server_b. I didn't want that. I was expecting unison to copy 
a.txt to server_a. 

  What do I need to do that?

Vivek

"Current stable version" for Windows?

I'm rather confused trying to find out which is the current stable
version to use under Windows, starting from the Downloads page at
http://www.cis.upenn.edu/~bcpierce/unison/download.html . 

- Clicking on the button "Current stable version" at
takes me to
http://www.seas.upenn.edu/~bcpierce/unison/download/releases/stable/
where I find a source tarball for 2.13.16.

- Clicking on the button "Windows and OS X binaries" takes me to Alan
Schmitt's page offering me to choose between 2.26.14, 2.27.36 and
2.28.17, without any hint about their stable or beta status.

- Clicking on the button "Older Windows binaries (pre-2.24)" takes me
to a directory where 2.24.6 seems to be the most recent version.

"pre-2.24" could be understood to mean that 2.24 is some kind of
landmark, so perhaps this means it actually is the (latest) stable
version - or that it *was* the latest stable at some moment?

And if it is actually the latest stable version, why is it not found
at the page of Alan Schmitt, nor is 2.13.16?

What about 2.27.x? According to Benjamin Pierce on 24 July, it is 
"ready [for common use] -- I am planning to promote it to stable
soon." Has it been promoted yet?

PLEASE, could you shed some light, and also update the links on the
Downloads page? I am having a hard time trying to
figure out which version I should recommend to someone which is very

Re: limiting remote usage

I'm under the impression you're behind a Unix machine, so take a look at sshd's
manpage (e.g. you're using OpenSSH), and especially the AUTHORIZED_KEYS FILE
FORMAT section. Take note of "command" and various other no-* options.
Then check out some chrooting/jailing apps, configure them, and add them to your
authorized_keys file under "command", and append unison -server.
Debian has schroot for user-level chrooting, so try to find something similar,
or make a quick compile and set it SUID root.

It's a rough outline, but add a spoonful of common logic, and serve.

Andri.

dportabella wrote:
> 
> 
> Hello,
> 
> I have a server and several users who need to synchronize from the
> server. The purpose of the sever is *only* to allow them to
> synchronize their files; nothing else should be permitted.
> 
> There are two options for this: using the "remote shell" method or the
> "socket" method. However, with both options, the users have too much
> "freedom".
> 
> With the "remote shell" option, it means that users can connect to the
> server and do other stuff other than syncrhonize files. For instance,
> they can run programs there. I really need to limit the server to
> synchronize files, nothing else. That's why I say that, in this
> set-up, the "remote shell" with the users too much "freedom".

RE: limiting remote usage

Hi All...

>From: "dportabella" Subject: [unison-users] limiting remote usage
>Date: Wed, 01 Aug 2007 10:15:36 -0000
>
>Hello,
>
>I have a server and several users who need to synchronize from the
>server. The purpose of the sever is *only* to allow them to
>synchronize their files; nothing else should be permitted.
>
>There are two options for this: using the "remote shell" method or the
>"socket" method. However, with both options, the users have too much
>"freedom".
>
>With the "remote shell" option, it means that users can connect to the
>server and do other stuff other than syncrhonize files. For instance,
>they can run programs there. I really need to limit the server to
>synchronize files, nothing else. That's why I say that, in this
>set-up, the "remote shell" with the users too much "freedom".
>
>The "socket" method removes the previous type of freedom. However,
>there are two things to solve:
>1- user authentication. How to restrict malicious users to use it?
>
>2- restrict operation. Depending on the user, I would like to restrict
>the paths that he can synchronize; maybe restrict whether they can
>update files from and to the client and the server, or only from the
>server to the client (-force rootPath). Maybe this could be achieved
>by having the unison profiles defined in the server, rather than in

Re: Deleting a local file while synchronizing

I'm surprised by the the behavior you report.  Is it repeatable?

    - Benjamin

On Aug 1, 2007, at 5:52 AM, viv_1005 wrote:

> Hello!
>   I am a new user to this mailing list. I am trying following.
>
> environment : Linux
> two servers: remote server : server_a
> local server: server_b
>
> I logged in to server_b
>
> I have following setup
>
> server_a: /home/myName/test_dir (test_dir contains a tree)
> server_b: /home/myName/          (nothing)
>
> I synchronized these things using unison. I used following command
>
> server_a:/> unison ssh://server_b//home/myName/test_dir /home/myName/
>
> This worked fine. Later, I added a file to server_b database
>
> (i.e. file a.txt was added at (server_b)/home/myName/test_dir
>
> I used the above command again. This time, unison deleted the file
> from server_b. I didn't want that. I was expecting unison to copy

Re: "Current stable version" for Windows?

OK, here's the scoop:

* 2.27 is working well.  I am hoping to promote it to stable status  
in the next few days.  (I want to make some very minor tweaks before  
doing that, but the stable version will be basically identical to  
what is there.)

* 2.13 remains the official stable version until I actually do this,  
but I don't recommend that people use it -- 2.27 is *much* better.

* 2.28 is also working fine, but the differences from 2.27 are in  
experimental parts of the code that will become part of the *next*  
round of beta- and stable releases, in the course of time.

Most people should use 2.27.

Regards,

    - Benjamin

On Aug 1, 2007, at 8:08 AM, yvesforkl wrote:

> I'm rather confused trying to find out which is the current stable
> version to use under Windows, starting from the Downloads page at
> http://www.cis.upenn.edu/~bcpierce/unison/download.html .
>
> - Clicking on the button "Current stable version" at
> takes me to
> http://www.seas.upenn.edu/~bcpierce/unison/download/releases/stable/
> where I find a source tarball for 2.13.16.

compilation error

hi list,

i've just downloaded the sources for 2.27.29 and tried to compile the gtk2-version. compilation fails
with the following error:

File "/home/joost/src/unison-2.27.29/uigtk2.ml", line 1575, characters 6-20:
Warning Y: unused variable mergeLogoBlack.
File "/home/joost/src/unison-2.27.29/uigtk2.ml", line 1573, characters 6-20:
Warning Y: unused variable leftArrowBlack.
File "/home/joost/src/unison-2.27.29/uigtk2.ml", line 1572, characters 6-21:
Warning Y: unused variable rightArrowBlack.
File "/home/joost/src/unison-2.27.29/uigtk2.ml", line 1559, characters 6-17:
Warning Y: unused variable yellowPixel.
File "/home/joost/src/unison-2.27.29/uigtk2.ml", line 68, characters 10-23:
Unbound value Gdk.Font.load
make: *** [uigtk2.cmx] Fout 2

(the warnings may be irrelevant. in fact, a few warnings were spit out earlier during compilation.)

OS: linux x86 (Zenwalk)

anyone have an idea what might be the problem?

TIA

--

-- 
Joost Kremers
Life has its moments

       

Uncaught Exception Gpointer.null

I want to synchronize files using unison over ssh. 
On both machines the same version is running: 2.17.1-20
Operating system on both machines: Suse Linux 10.2
The remote machine is a 64 bit computer and therefore on this machine
the 64-bit rpm of unison is installed.

Could that be the reason of the problem?

The command unison -debug all gives the output:

    [startup] Preferences:
    ui = graphic
    host =
    server = false
    prefsdocs = false
    doc =
    version = false
    silent = false
    dumbtty = false
    testserver = false
    rest = FG Backup
    confirmmerge = true
    retry = 0
    repeat =
    contactquietly = false
    key =
    label =
    expert = false
    reusewindows = false
    height = 20

Re: Deleting a local file while synchronizing