When I try to resize a window in vim by dragging it's status line with the mouse as a normal user the window is not resized. This happens only on the console. In xterm and in gvim it works just fine. Cut and paste works too, even on the console. And mouse _clicks_ (or doubleclicks) in other applications like mc and links do work fine as well. Resizing windows in vim with the mouse does work as root. When I use vim as root I can resize windows by dragging the status line with mouse, even on the console. Reproducible: Always Steps to Reproduce: 1. emerge gvim gpm 2. switch to a virtual console and open vim 3. :sp 4. try to drag a window's status line. it will only work if you are root. Actual Results: As a normal user, dragging the status line with the mouse selects an area. Expected Results: The status line should have been dragged and the window should have been resized. I am using devfsd. I tried fiddling around with the permissions to /dev/gpmctl but it did not help. I noticed something else as well though: Initially after boot, root owns /dev/gpmctl, the gid is root, and all permission bits are set (ie rwxrwxrwx). When a user starts working with a gpm application like vim or mc the file ownership is changed to her user uid, and permissions are cut down to rwx------. As a result other users cannot use all features of gpm anymore (mouse clicks in mc don't work anymore for other users, for example). Cut and paste still works though, and root can (as usual) still do anything. The "sticky bit" (s) is set as well on /dev/gpmctl, but I have to admit that I don't know yet what that flags actually does... To me, the issue looks like a permission problem with gpm.
This is working fine for me with vim-6.2-r5 gpm-1.20.1 devfsd-1.3.25-r5 pam-0.77 I am also running a 2.6 kernel but I don't think that should matter. From what I can see, gpmctl maintains root ownership, perms=srwxrwxrwx, regardless of what application is running on the console. I am able to drag the status line with the mouse as a normal user. Is this still a problem for you? What versions are you running?
I am now running the same versions, but the problem persists. I noticed that the permissions of /dev/gpmctl change as soon as a user logs in on a tty. any thoughts?
I haven't been able to reproduce this yet. Could you do some debugging with strace to see what is changing the permissions of the device special file?
When a user logs in, the permissions are changed fom owner: root (rwxrwxrwx) to owner: user (rwx------) When user logs out again perms are changed to owner: root (rwx------) The group and other perm-bits are never being restored. How can I use strace to monitor a socket (/dev/gpmctl)? Since the permissions are changged as soon as a user logs in, I could monitor agetty... but I doubt very very much that agetty does change permissions of /dev/gpmctl. Its much more likely that I misconfigured devfsd. I remember that when I first discovered the issue, I played around with changing ownerships of /dev/gpmctl in order to find out whether the problem was permission related. So maybe devfsd remembers the perm-settings I made back then and always sets permissions of /dev/gpmctl accordingly. I will try throwing out devfsd and see what happens.
Created attachment 23785 [details] root's strace log
Created attachment 23786 [details] user's strace log
now first tried the following: logged in as user on a tty logged in as root on another tty changed permissions of /dev/gpmctl to srwxrwxrwx 1 root root 0 2004-01-14 10:03 /dev/gpmctl= called 'strace vim 2> log' once as root and once as user :sp tried moving the window statusbar with the mouse, works for root, not for user :q :q a search for gpm in root's log gives 2 hits: open("/usr/lib/libgpm.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260\30"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=24261, ...}) = 0 mmap2(NULL, 22520, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x404b2000 mprotect(0x404b7000, 2040, PROT_NONE) = 0 mmap2(0x404b7000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x4) = 0x404b7000 close(3) = 0 connect(4, {sa_family=AF_UNIX, path="/dev/gpmctl"}, 13) = 0 write(4, "\16\0\377\376\0\0\377\377\222P\0\0\2\0\0\0", 16) = 16 rt_sigaction(SIGWINCH, {0x405faf70, [], SA_RESTORER, 0x4068c358}, {0x405faf70, [], SA_RESTORER, 0x4068c358}, 8) = 0 rt_sigaction(SIGTSTP, {SIG_IGN}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGTSTP, {0x405faf70, [], SA_RESTORER|SA_NOMASK, 0x4068c358}, NULL, 8) = 0 rt_sigaction(SIGTSTP, {SIG_DFL}, {0x405faf70, [], SA_RESTORER|SA_NOMASK, 0x4068c358}, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [TSTP], NULL, 8) = 0 ioctl(1, SNDCTL_TMR_TIMEBASE, {B38400 opost -isig -icanon -echo ...}) = 0 brk(0) = 0x8358000 brk(0x8359000) = 0x8359000 getuid32() = 0 /dev/gpmctl is closed some 400 lines later... for user searching log for gpm gives only one hit: open("/usr/lib/libgpm.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260\30"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=24261, ...}) = 0 mmap2(NULL, 22520, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x404b2000 mprotect(0x404b7000, 2040, PROT_NONE) = 0 mmap2(0x404b7000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x4) = 0x404b7000 close(3) = 0 this does not differ with the first hit root got... so question is why has user only got one hit? I attached the complete logs.
As usual, the problem was obviously somewhere else then I was looking... The bad guy was a small line in my user's .vimrc set ttymouse=xterm2 Removed that and everything works fine now. Thanks very much for your help and time.
Great! Nice debugging work. I'm glad you found this, because I wasn't figuring it out very quickly... ;-)
