Re: 2 problems using screen with sshfs and symlinks

[Stephane Chazelas]

On Wed, Aug 06, 2008 at 07:44:32AM -0700, Ken Steen wrote:
> I have a small file manager that uses screen to open programs in new
> screen windows.  It works correctly except when using screen on a
> directory mounted with sshfs or when using screen on a directory that is
> a symbolic link.  If the program is started with 'screen program-name',
> and the current directory is a symbolic link to another directory
> opening a new screen window changes the pwd to the directory that is
> pointed to by the symbolic link instead of the symbolic link directory.
> If the program is started in the shell without screen and then opens a
> screen window the pwd is the symbolic link directory.  

There is no such thing as a "symbolic link directory". A
symbolic link is a special kind of file that contains a
path to another file. When you chdir(2) with a patch to such a
file as argument, you end up in the directory that is the target
of that link.

The current working directory is always a directory, and there
is no path involved. The system knows the current directory only
by the device it's on and its inode.

A user (or sometimes the kernel as on Linux' /proc/<pid>/cwd)
may compute a path to that directory, by recursively looking up
the ".." entried starting from the current directory, but that's
all.

Now, some shell implementations have a feature (which I tend to
consider as a misfeature as it causes more confusion that it
helps) in which they maintain an internal "logical"
representation of the current working directory. It started with
ksh I think and other shells like zsh and bash copied it. It's
stored in the $PWD parameter. The shell uses that internal
parameter for its pwd builtin (with pwd -L, the default, not pwd
-P) and cd (cd -L, the default, not cd -P) when arguments
contain ".."

Even though POSIX prohibits it, if $PWD is found in the
environment, shells, upon startup initialise their internal
"logical current directory" parameter with its value (as long as
it is a valid path to the current working directory).

I think it is what you're observing above.

If you have:
~$ ls -ld 1 2
drwxr-xr-x 2 chazelas chazelas 4096 2008-08-11 12:00 1/
lrwxrwxrwx 1 chazelas chazelas    1 2008-08-11 12:00 2 -> 1/

And the current directory is "/tmp".

If you do a:

$ cd 2

Your current directory will be the /tmp/1 directory. However,
your shell will store "/tmp/2" in the $PWD variable, and if you
run the "pwd" command, it will return the content of that
variable instead of the real working directory.

Now, your shell exports $PWD to the environment, so if you start
another shell, it will inherit the $PWD, and if you run the pwd
command in that other shell, it will return /tmp/2 as well.

But if you start that other shell with "screen". The $PWD
variable will not be inherited. The new shell will be a child of
the screen server, so will inherit the $PWD of that process, not
the $PWD of your current shell.

What you could do is:

screen env PWD="$PWD" some-program

> A similar problem
> occurs when a directory  is mounted with sshfs.  If the program is
> started with 'screen program-name' screen will give a permission denied
> message when trying to open a new screen window.  If the program is
> started in a shell without screen and trys to open a sshfs mounted
> directory in a screen window it works correctly.
> 
> I am not sure what is happening.  I am guessing that the environ
> variable is not being set correctly.  The screen command is passed with 
> execve() and works correctly except in the previous two examples.  Any
> ideas into what I am doing wrong would be greatly appreciated.
[...]

When you do:

screen some-command

in directory /dir.

That screen command tells the screen server to open a new
window, to do a chdir("/dir") in it and execute the command as
the current user.

If it does the chdir() before switching persona, then you'll
have the problem because by default sshfs doesn't allow root to
access directories mounted by a user.

Maybe screen should be modified so that the chdir() is performed
after switching persona.

-- 
Stéphane