Cut'n'Paste via *p and different users
Hi, I often edit some system related files as root while haveing cat-ed related (text-) material as user on another terminal. Trying to do the following under X and with mrxvt as termulator does not work: sux root password vim a system file (and as user at another termulator-window): cat a file selecting some text (back to the rooted vim: ) *p Doing both as user works nicely. Is it possible to Cut(user)'n'Paste(root) somehow? Is this a problem of security settiongs, of permission settings or of me myself ? ;) Ah! by the way: I am running Gentoo linux (updated on a daily basis) and I am using vim via the console (mrxvt termulator) under X. Thanks a lot for any help in advance! Keep editing! mcc
Re: Cut'n'Paste via *p and different users
Meino Christian Cramer wrote:
Hi,
I often edit some system related files as root while haveing cat-ed related
(text-) material as user on another terminal.
Trying to do the following under X and with mrxvt as termulator does not work:
sux root
password
vim a system file
(and as user at another termulator-window):
cat a file
selecting some text
(back to the rooted vim: )
*p
Doing both as user works nicely.
Is it possible to Cut(user)'n'Paste(root) somehow? Is this a problem
of security settiongs, of permission settings or of me myself ? ;)
Ah! by the way: I am running Gentoo linux (updated on a daily basis)
and I am using vim via the console (mrxvt termulator) under X.
Thanks a lot for any help in advance!
Keep editing!
mcc
If it doesn't work via the clipboard, try the older (pre-clipboard) method,
using an auxiliary file:
:[range]w {filename} write lines (from) (to)
:[line]r {filename} read after (line)
or before line 1 if (line) == 0
User - root should work with no problem. For root - user you might need
:!chmod {filename} a+r
in between, to give everyone read permission.
Best regards,
Tony.
Re: Cut'n'Paste via *p and different users
From: A.J.Mechelynck [EMAIL PROTECTED]
Subject: Re: Cut'n'Paste via *p and different users
Date: Wed, 25 Oct 2006 14:28:23 +0200
Meino Christian Cramer wrote:
Hi,
I often edit some system related files as root while haveing cat-ed related
(text-) material as user on another terminal.
Trying to do the following under X and with mrxvt as termulator does not
work:
sux root
password
vim a system file
(and as user at another termulator-window):
cat a file
selecting some text
(back to the rooted vim: )
*p
Doing both as user works nicely.
Is it possible to Cut(user)'n'Paste(root) somehow? Is this a problem
of security settiongs, of permission settings or of me myself ? ;)
Ah! by the way: I am running Gentoo linux (updated on a daily basis)
and I am using vim via the console (mrxvt termulator) under X.
Thanks a lot for any help in advance!
Keep editing!
mcc
If it doesn't work via the clipboard, try the older (pre-clipboard) method,
using an auxiliary file:
:[range]w {filename} write lines (from) (to)
:[line]r {filename} read after (line)
or before line 1 if (line) == 0
User - root should work with no problem. For root - user you might need
:!chmod {filename} a+r
in between, to give everyone read permission.
Best regards,
Tony.
Hi Tony,
thank you for your reply, Tony !
I know that temporary-file-trick already (it is one of two things,
which I know before the other thing is how to start vim ;)))
I was wondering, whether the clipboard-problem is caused by some
(possible wrong) settings of my system or a normal behaviour of
X/mrxvt and whether there are tricks to make the clibboard working
inter-user-al :) ... it is so cool to use *p !!!
Keep hacking!
mcc
Re: Cut'n'Paste via *p and different users
I was wondering, whether the clipboard-problem is caused by some (possible wrong) settings of my system or a normal behaviour of X/mrxvt and whether there are tricks to make the clibboard working inter-user-al :) ... it is so cool to use *p !!! The following information is 100% untested, but my understanding is that the X server has to be authorized (via the MIT Magic Cookie) to accept connections from clients. Quoting directly from Loren M. Lang's post (found at http://groups.google.com/group/mailing.freebsd.questions/browse_thread/thread/dc2159c366eb9064/e9001ce2abaec9d3?lnk=stq=run+x+application+as+different+userrnum=4#e9001ce2abaec9d3 sorry for the long link) [begin quote]-- 3)what must i put in the .Xauthority file to make the screensaver work with having to use xhost ? When X first logs in to a user, it creates the .Xauthority file in that users home directory and fills it with a random string called a MIT-MAGIC-COOKIE. Any X client, by default, reads that file to see what the cookie is then sends it to the X server to authenticate itself. Anyone who can read that file can access the display so that file is normally only readable by the user who logged in, though root can always read it because root is god. When you run an X program as a different user, it will look in that users home directory for the .Xauthority file and so won't be able to find the right cookie unless you used the xauth command to give that user the cookie ahead of time. By setting the XAUTHORITY environment variable to some other file, it will check that file for the magic cookie instead of the current users home directory. This is useful when running a command as root that you want to access a normal users X server. This is a much more secure way to allow access to X than using xhost since you know what users are able to access X, not just which computers, which may have multiple users on them. In summary, don't touch xhost, just use: XAUTHORITY=/home/user/.Xauthority xscreensaver or you can use xauth to extract the magic cookie and then import it into the correct users .Xauthority file. As the user of the X server: xauth extract my-cookie-file $DISPLAY Saves the magic cookie to a file called my-cookie-file for the current display. Then as the user who want to access the X display: xauth merge my-cookie-file Adds the cookie stored in my-cookie file to the current users .Xauthority file. Now user B can open an X application on A's X server. Oh, and don't run xscreensaver as root EVER! Instead, if you're really paranoid about security, make a user who can access any of your files whose sole purpose is to run xscreensaver then use that user to run it. This is still not that much more secure since any user that can access an X server can essentially take it over and control your mouse and keyboard doing what ever they want, like openning an xterm on your display and running the passwd command to change your passwd. Now they just gained access to all your files as well. [end quote]-- My guess is that, as root, you want to try something like XAUTHORITY=/home/user/.Xauthority gvim file1.txt The old-school way of doing this was to tinker with xhost to allow a whole host (rather than a particular user) to connect to the X server. The aim is to allow your alternate user (root in this case) permission to connect to the X server so that it can access the clipboard(s). My understanding is that the keys found in the .Xauthority file are the way to do this...that the alternate user has to have the key. Or I could be talking bunk. YMMV :) -tim
Re: Cut'n'Paste via *p and different users
From: Tim Chase [EMAIL PROTECTED] Subject: Re: Cut'n'Paste via *p and different users Date: Wed, 25 Oct 2006 08:19:29 -0500 I was wondering, whether the clipboard-problem is caused by some (possible wrong) settings of my system or a normal behaviour of X/mrxvt and whether there are tricks to make the clibboard working inter-user-al :) ... it is so cool to use *p !!! The following information is 100% untested, but my understanding is that the X server has to be authorized (via the MIT Magic Cookie) to accept connections from clients. Quoting directly from Loren M. Lang's post (found at http://groups.google.com/group/mailing.freebsd.questions/browse_thread/thread/dc2159c366eb9064/e9001ce2abaec9d3?lnk=stq=run+x+application+as+different+userrnum=4#e9001ce2abaec9d3 sorry for the long link) snipped but never forgotten! :) My guess is that, as root, you want to try something like XAUTHORITY=/home/user/.Xauthority gvim file1.txt The old-school way of doing this was to tinker with xhost to allow a whole host (rather than a particular user) to connect to the X server. The aim is to allow your alternate user (root in this case) permission to connect to the X server so that it can access the clipboard(s). My understanding is that the keys found in the .Xauthority file are the way to do this...that the alternate user has to have the key. Or I could be talking bunk. YMMV :) -tim Hi Tim ! thanks a lot for that ! Simply: IT WORKS! Keep hacking! mcc
Re: Cut'n'Paste via *p and different users
XAUTHORITY=/home/user/.Xauthority gvim file1.txt The old-school way of doing this was to tinker with xhost to allow a whole host (rather than a particular user) to connect to the X server. The aim is to allow your alternate user (root in this case) permission to connect to the X server so that it can access the clipboard(s). My understanding is that the keys found in the .Xauthority file are the way to do this...that the alternate user has to have the key. Or I could be talking bunk. YMMV :) thanks a lot for that ! Simply: IT WORKS! Other suggestions I've heard include, rather than *being* root, to try (as user) [EMAIL PROTECTED] sudo gvim file1.txt (assuming you have sudo configured to allow you to run gvim) which for some reason should work as well. I've actually done this one, whereas my previous ramble was 100% untested. I'm glad it worked. Other ideas I've heard include creating a soft-link: [EMAIL PROTECTED] ln -s ~user/.Xauthority ~/.Xauthority which doesn't work quite as well for non-root situations unless you explicitly share your ~user/.Xauthority file permission-wise, such as [EMAIL PROTECTED] chmod ug+r ~/.Xauthority [EMAIL PROTECTED] chown :alteregos ~/.Xauthority [EMAIL PROTECTED] su -c user2 [EMAIL PROTECTED] ln -s ~user1/.Xauthority ~/.Xauthority (those permissions *might* need to be ug+rw, but I'm not sure on that) This assumes that user1 and user2 are members of hte alteregos group. However, if you log in from [xkg]dm as user2 (or startx as user2), it might try and overwrite user1's .Xauthority file, which, if permissions aren't granted, might cause grief. Not always a bad thing if only one person is logged on at a time, but if you have fast user switching (which, in the implementations I've seen, is done by running multiple X servers on multiple consoles), you might have some trouble. Just a few more ideas to play with. -tkc
