Subject: 2 problems using screen with sshfs and symlinks

From: Ken Steen <[email-masked]>
Date: Wed, 6 Aug 2008 07:44:32 -0700

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.  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.

Ken

_______________________________________________
screen-users mailing list
[email-masked]
http://lists.gnu.org/mailman/listinfo/screen-users

---

From: "Trent W. Buck" <[email-masked]>
Date: Sun, 10 Aug 2008 12:38:17 +1000

On Wed, Aug 06, 2008 at 07:44:32AM -0700, Ken Steen wrote:
> If [my] 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.

Does this problem occur with other terminal emulators (than screen)?

    xterm -hold -e program-name
    rxvt -e program-name
    gnome-terminal -x program-name

---

From: "Andy Harrison" <[email-masked]>
Date: Sun, 10 Aug 2008 21:18:21 -0400

> ideas into what I am doing wrong would be greatly appreciated.

Although completely unrelated to screen, I had similar permission
problems with one of my sshfs mounts.  I finally solved it with the
following sshfs params:

sshfs my_username@servername:/path /mount/point -o allow_root -o
idmap=user -o uid=1000 -o gid=1000

I would suggest trying that, or change allow_root to allow_other, and
see if that helps.

-- 
Andy Harrison
public key: 0x67518262

---

From: "Trent W. Buck" <[email-masked]>
Date: Mon, 11 Aug 2008 11:23:07 +1000

On Sun, Aug 10, 2008 at 09:18:21PM -0400, Andy Harrison wrote:
> following sshfs params: [... -o allow_root]

Hmm -- perhaps this is related to screen being set-uid?  Perhaps it
does some things as root before relinquishing privileges that it
should be doing as the non-privileged user?

---

From: Ken Steen <[email-masked]>
Date: Sun, 10 Aug 2008 21:50:45 -0700

> I would suggest trying that, or change allow_root to allow_other, and

I had to use the -o allow_other and -o default_permissions with sshfs to
get it to work properly with screen.  The symlink directory problem was
fixed by calling "screen -X setenv PWD /full/path/to/directory"  before
calling screen to open a new window.  I don't know why it is needed only
on symlink directories but it works.

Thanks,
Ken

---

From: Stephane Chazelas <[email-masked]>
Date: Mon, 11 Aug 2008 12:11:17 +0100

> 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
[...]

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