headers
Miklos Szeredi | 4 Dec 2007 11:03
Picon

Re: [sshfs] sshfs mounted applications fail with "error loading shared libraries"

> On Dec 3, 2007 5:19 AM, Miklos Szeredi <miklos <at> szeredi.hu> wrote:
> > > Yes it is weird. I hope you can help me with this problem as sshfs is
> > > so much simpler than nfs.
> >
> > Can you please do one more thing: start up sshfs normally, then on the
> > server do a strace of the sftp-server process:
> >
> >  strace -o /tmp/strace.log -p `pidof sftp-server`
> 
> Attached the sftp-server log.

Thanks.  I think I can see the explanation.  Here's the failure:

   read(3, "\0\0\0H\3\0\0\3\347\0\0\0003/mnt/exports/tools/"..., 16384) = 140
   open("/mnt/exports/tools/ISE9.2i/bin/lin64/libXst_Core.so", O_RDONLY) = 105
   close(105)                              = 0
   select(5, [3], [4], NULL, NULL)         = 1 (out [4])
   write(4, "\0\0\0\30e\0\0\3\347\0\0\0\4\0\0\0\7Failure\0\0\0\0", 28) = 28

The file handle is 105, which suggests, that there's some limit around
100 open files.  Looking at the sftp-server source confirms this:

   Handle  handles[100];

So, unfortunately it seems sftp-server can only handle 100 open files
at a time.

It's easy enough to fix, if you are willing to recompile the
sftp-server binary.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vasanth Asokan | 6 Dec 2007 01:24
Picon

Re: [sshfs] sshfs mounted applications fail with "error loading shared libraries"

On Dec 4, 2007 2:03 AM, Miklos Szeredi <miklos <at> szeredi.hu> wrote:
>
> > On Dec 3, 2007 5:19 AM, Miklos Szeredi <miklos <at> szeredi.hu> wrote:
> > > > Yes it is weird. I hope you can help me with this problem as sshfs is
> > > > so much simpler than nfs.
> > >
> > > Can you please do one more thing: start up sshfs normally, then on the
> > > server do a strace of the sftp-server process:
> > >
> > >  strace -o /tmp/strace.log -p `pidof sftp-server`
> >
> > Attached the sftp-server log.
>
> Thanks.  I think I can see the explanation.  Here's the failure:
>
>    read(3, "\0\0\0H\3\0\0\3\347\0\0\0003/mnt/exports/tools/"..., 16384) = 140
>    open("/mnt/exports/tools/ISE9.2i/bin/lin64/libXst_Core.so", O_RDONLY) = 105
>    close(105)                              = 0
>    select(5, [3], [4], NULL, NULL)         = 1 (out [4])
>    write(4, "\0\0\0\30e\0\0\3\347\0\0\0\4\0\0\0\7Failure\0\0\0\0", 28) = 28
>
> The file handle is 105, which suggests, that there's some limit around
> 100 open files.  Looking at the sftp-server source confirms this:
>
>    Handle  handles[100];
>
> So, unfortunately it seems sftp-server can only handle 100 open files
> at a time.
>
> It's easy enough to fix, if you are willing to recompile the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Miklos Szeredi | 6 Dec 2007 22:48
Picon

Re: [sshfs] sshfs mounted applications fail with "error loading shared libraries"

> > It's easy enough to fix, if you are willing to recompile the
> > sftp-server binary.
> >
> 
> Thanks Miklos. I guess arbitrarily increasing the number of handles is
> not a good long term fix. It is hard to guesstimate how many clients
> can be supported through a single sshfs mounted file system if there
> is a fundamental file handle limit in sftp-server. Making it 1000 is
> going to fail somewhere else down the line. Is that correct?

That depends on how long these files are kept open.  But in theory
yes, that could happen.

Ideally sftp-server should allocate the space for handles dynamically,
so a hardcoded limit wouldn't be needed.  There are still various
limits on the number open files, but those can easily be adjusted by
the sysadmin.

Miklos

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
Permalink | Reply | 0 comments |
headers
Larry Becke | 7 Dec 2007 00:26
Picon
Favicon

scp -t - revisited.....


Okay - We went around and around on the idea that adding an option to restrict scp to only allow files to be
copied to a certain directory (or below) based on a different startup param.

I was told to use all sorts of different options, parameters, methods, etc...   All because no one wanted to
modify the scp code, for whatever reasoning.

I'm sitting here laughing right now, seriously laughing, because the request was un-necessary.  scp
already has that functionality built into it, whether it was intentional or not.

Here's the deal.

we set up a key on the client side, and the systems admin places the public component of the key into the users
authorized_keys file with the command attribute set.

command="/usr/local/bin/scp -t /data/work/test" ssh-dss AAAAB3keycodefollows......

Then when the client issues the command

scp -i test_key /path/to/filename user <at> remotehost:

It copies the to the remote host into the directory specified in the command= option.

Now, at first glance, you're probably thinking  - wth is he talking about?  so what?

We had been using this for a while, and within the last few days had the first user attempt to rename a file in transit.

scp -i test_key /path/to/filename user <at> remotehost:filename.0001

The only problem was, that the file was always copied with the original filename.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Damien Miller | 7 Dec 2007 00:58
Favicon

Re: [sshfs] sshfs mounted applications fail with "error loading shared libraries"

On Thu, 6 Dec 2007, Miklos Szeredi wrote:

> That depends on how long these files are kept open.  But in theory
> yes, that could happen.
> 
> Ideally sftp-server should allocate the space for handles dynamically,
> so a hardcoded limit wouldn't be needed.  There are still various
> limits on the number open files, but those can easily be adjusted by
> the sysadmin.

Yes, sftp-server should dynamically allocate its handles up to the
point where the system starts refusing to allocate file descriptors.

Anyone want to make a patch?

-d
Permalink | Reply | 0 comments |
headers
Larry Becke | 7 Dec 2007 01:00
Picon
Favicon

scp -t - revisited.....


Oh- it also makes the scp send only.

ie - you cannot copy a file from the remote host, to the local host.

_________________________________________________________________
Put your friends on the big screen with Windows Vista® + Windows Live™.
http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_102007
Permalink | Reply | 1 comment |
headers
Peter Stuge | 7 Dec 2007 02:02

Re: scp -t - revisited.....

On Thu, Dec 06, 2007 at 05:26:14PM -0600, Larry Becke wrote:
> This leads me to believe that using the scp -t
> /some/path/to/a/directory  command= in the authorized_keys file
> causes scp to forget/ignore everything after the remote hostname.

There is one more step between the remote scp (run with -t) and the
"remote filename" as specified in the local shell: The local scp.

> This gives us almost exactly what we were looking for

I think that depends on the local scp program.

What happens if you (within the scp protocol, not in the shell)
specify e.g. a new directory ../../../../../../../tmp/breakout ?

I would assume that /tmp/breakout is created.

If your local scp program is trusted then you're all set. But if that
was the case why bother with locking down the server?

> Like I said, I'm sitting here laughing right now, mostly because it
> was a lot of wasted effort on all sides to argue (or discuss with
> pointed statements) over something that already existed, even if it
> wasn't known or documented.

I still believe there was a good reason for that argument.

> (Wonders if this will be considered a bug to be fixed or quashed as
> it wasn't an intended *feature* of scp)....   I hope not...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jan Pechanec | 7 Dec 2007 01:25
Picon

Re: scp -t - revisited.....

On Thu, 6 Dec 2007, Larry Becke wrote:

>This leads me to believe that using the scp -t /some/path/to/a/directory 
>command= in the authorized_keys file causes scp to forget/ignore everything 
>after the remote hostname.

	internally, local scp runs "ssh <HOST> scp -t/-f <PATH>". With 
command= in authorized keys file, the command set on ssh command line is 
ignored and "command=..." is used instead.

> (Wonders if this will be considered a bug to be fixed or quashed as it 
>wasn't an intended *feature* of scp)....  I hope not...

	it has nothing to do with scp. The local scp process doesn't know 
about it at all, neither the scp process on remote side.

--

-- 
Jan Pechanec
Permalink | Reply | 0 comments |
headers
Jan Pechanec | 7 Dec 2007 01:28
Picon

Re: scp -t - revisited.....

On Thu, 6 Dec 2007, Larry Becke wrote:

>Oh- it also makes the scp send only.
> 
>ie - you cannot copy a file from the remote host, to the local host.

	correct. For copying from remote side, you run that internall ssh 
with (slightly simplified) "scp -f <FILE>". Well, you could set another key 
and you could always copy the same file :-)

--

-- 
Jan Pechanec
Permalink | Reply | 0 comments |
headers
Larry Becke | 7 Dec 2007 02:58
Picon
Favicon

scp -t - revisited


Thanks to J.P. I now have a better understanding of how scp really works.

I haven't uncovered any dark secrets, or unintended capabilities, I just prevented scp from sending the
proper commands via ssh to the remote server.

In essence, I gave scp a lobotomy or short-circuit.   

Either way, it's useful and gives me the desired effect.

I don't know if anyone else would find this useful or not, but if you'd like the specifics, I can share them.

_________________________________________________________________
Connect and share in new ways with Windows Live.
http://www.windowslive.com/connect.html?ocid=TXT_TAGLM_Wave2_newways_112007
Permalink | Reply | 1 comment |

Gmane