Hello,
I think another thing on all of our minds should be towards dealing with the problems related to sudo. As we know not all distros support it, and also removing sudo in cases can remove the entire trinity install, wreak havoc and other terrible things.
Do we have a plan for this? Tim what needs to be done?
Calvin
On Saturday 26 November 2011 11:15:19 am Calvin Morrison wrote:
Hello,
I think another thing on all of our minds should be towards dealing with the problems related to sudo. As we know not all distros support it, and also removing sudo in cases can remove the entire trinity install, wreak havoc and other terrible things.
Do we have a plan for this? Tim what needs to be done?
Some people don't even use sudo, and not all distros use it, even if they have it installed by default.
I don't think sudo should be a dependency.
Also, why does trinity have it's own sudo? I'd think it should be able to find it in $PATH?
I don't think sudo should be a dependency.
It only is a dependency on distributions that use sudo in their core packages such as Ubuntu.
Also, why does trinity have it's own sudo? I'd think it should be able to find it in $PATH?
Look up the sudo RPATH "feature". Basically if the application is not present in /usr/bin or a handful of other hardcoded directories sudo won't find it.
Tim
On Saturday 26 November 2011 01:31:45 pm Timothy Pearson wrote:
I don't think sudo should be a dependency.
It only is a dependency on distributions that use sudo in their core packages such as Ubuntu.
Also, why does trinity have it's own sudo? I'd think it should be able to find it in $PATH?
Look up the sudo RPATH "feature". Basically if the application is not present in /usr/bin or a handful of other hardcoded directories sudo won't find it.
I never heard of RPATH.
Wouldn't it be possible to include the binaries in /opt/trinity/bin in the sudoers file? If sudoers doesn't accept wildcards like '*', that would be impractical, but if so, that should be possible without having to replace the distro's sudo. Some distro maintainers won't be happy with us interfering with their sudo packages (or, generally, more packages than absolutely necessary, or really any packages at all, and might refuse support to unofficial packages if they interfere with official packages).
Le 26/11/2011 19:31, Timothy Pearson a écrit :
I don't think sudo should be a dependency.
It only is a dependency on distributions that use sudo in their core packages such as Ubuntu.
Also, why does trinity have it's own sudo? I'd think it should be able to find it in $PATH?
Look up the sudo RPATH "feature". Basically if the application is not present in /usr/bin or a handful of other hardcoded directories sudo won't find it.
What are the trinity executables that really need to run with sudo?
(I have no /opt/trinity/sbin and apps in /opt/trinity/bin may be run with sudo `which ...`.)
What are the trinity executables that really need to run with sudo?
As an example, anything that needs root access in kcontrol. Some users also like to use sudo to launch a root-permissioned kwrite or konqueror.
(I have no /opt/trinity/sbin and apps in /opt/trinity/bin may be run with sudo `which ...`.)
Yes, but is this with the stock sudo? I would be very surprised if that were true.
Tim
Le 26/11/2011 20:38, Timothy Pearson a écrit :
(I have no /opt/trinity/sbin and apps in /opt/trinity/bin may be run with sudo `which ...`.)
Yes, but is this with the stock sudo? I would be very surprised if that were true.
For the moment, with Trinity's sudo, sudo `which ...` works with executables in $HOME/bin that aren't in the secure path of sudo (AFAIK 'which' is called before 'sudo').
I just replaced /usr/bin/sudo, and /usr/lib/sudo/sudo_noexec.so by debian versions (and added /usr/lib/sudo/sudoers.so) and everything works.
$ sudo `which kwrite` Error: "/var/tmp/kdecache-eldi" is owned by uid 1000 instead of uid 0.
$ sudo `which konqueror` Error: "/var/tmp/kdecache-eldi" is owned by uid 1000 instead of uid 0. Error: "/tmp/kde-eldi" is owned by uid 1000 instead of uid 0. Error: "/tmp/ksocket-eldi" is owned by uid 1000 instead of uid 0. Error: "/var/tmp/kdecache-eldi" is owned by uid 1000 instead of uid 0. Error: "/var/tmp/kdecache-eldi" is owned by uid 1000 instead of uid 0. Error: "/var/tmp/kdecache-eldi" is owned by uid 1000 instead of uid 0. Error: "/var/tmp/kdecache-eldi" is owned by uid 1000 instead of uid 0.
I added: Defaults secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/opt/trinity/bin:/usr/bin:/opt/trinity/sbin:/sbin:/bin:/usr/X11R6/bin in /etc/sudoers: 'sudo kwrite' and 'sudo konqueror' worked perfectly (with the same error messages but that's the same messages with Trinity's version).
On Sat, Nov 26, 2011 at 15:16, Laurent Dard f.couperin@online.fr wrote:
Le 26/11/2011 20:38, Timothy Pearson a écrit :
(I have no /opt/trinity/sbin and apps in /opt/trinity/bin may be run with sudo `which ...`.)
Yes, but is this with the stock sudo? I would be very surprised if that were true.
For the moment, with Trinity's sudo, sudo `which ...` works with executables in $HOME/bin that aren't in the secure path of sudo (AFAIK 'which' is called before 'sudo').
I just replaced /usr/bin/sudo, and /usr/lib/sudo/sudo_noexec.so by debian versions (and added /usr/lib/sudo/sudoers.so) and everything works.
$ sudo `which kwrite` Error: "/var/tmp/kdecache-eldi" is owned by uid 1000 instead of uid 0.
$ sudo `which konqueror` Error: "/var/tmp/kdecache-eldi" is owned by uid 1000 instead of uid 0. Error: "/tmp/kde-eldi" is owned by uid 1000 instead of uid 0. Error: "/tmp/ksocket-eldi" is owned by uid 1000 instead of uid 0. Error: "/var/tmp/kdecache-eldi" is owned by uid 1000 instead of uid 0. Error: "/var/tmp/kdecache-eldi" is owned by uid 1000 instead of uid 0. Error: "/var/tmp/kdecache-eldi" is owned by uid 1000 instead of uid 0. Error: "/var/tmp/kdecache-eldi" is owned by uid 1000 instead of uid 0.
Of course `which <exe>` would work, that searches the PATH and /opt/trinity/bin and /opt/trinity/sbin is in the PATH. That would work with normal sudo too.
On Saturday 26 November 2011 19:38:55 Timothy Pearson wrote:
What are the trinity executables that really need to run with sudo?
As an example, anything that needs root access in kcontrol. Some users also like to use sudo to launch a root-permissioned kwrite or konqueror.
That is surely only true of Kubuntu. On Debian I use su for root access to KControl.
Lisi
On Saturday 26 November 2011 04:21:34 pm Lisi wrote:
On Saturday 26 November 2011 19:38:55 Timothy Pearson wrote:
What are the trinity executables that really need to run with sudo?
As an example, anything that needs root access in kcontrol. Some users also like to use sudo to launch a root-permissioned kwrite or konqueror.
That is surely only true of Kubuntu. On Debian I use su for root access to KControl.
That is true for anybody who prefers sudo. If I recall correctly, doing "kdesudo /opt/trinity/bin/kcmshell 'kdm'" and typing your password does the same as using kdesu instead and typing root's password.
Though for some reason, even on Debian, kdesu asks for my password instead of root's. If I try typing root's password, it tells me I gave it the wrong password. It works fine with my normal user password.
Either way,
With Trinity expanding onto non debian systems I think its important to help remove some of the Ubuntu "hacks"
Calvin On Nov 26, 2011 4:59 PM, "Kristopher John Gamrat" chaotickjg@gmail.com wrote:
On Saturday 26 November 2011 04:21:34 pm Lisi wrote:
On Saturday 26 November 2011 19:38:55 Timothy Pearson wrote:
What are the trinity executables that really need to run with sudo?
As an example, anything that needs root access in kcontrol. Some users also like to use sudo to launch a root-permissioned kwrite or
konqueror.
That is surely only true of Kubuntu. On Debian I use su for root access
to
KControl.
That is true for anybody who prefers sudo. If I recall correctly, doing "kdesudo /opt/trinity/bin/kcmshell 'kdm'" and typing your password does the same as using kdesu instead and typing root's password.
Though for some reason, even on Debian, kdesu asks for my password instead of root's. If I try typing root's password, it tells me I gave it the wrong password. It works fine with my normal user password.
-- Kristopher Gamrat Ark Linux webmaster http://www.arklinux.org/
Le 26/11/2011 22:59, Kristopher John Gamrat a écrit :
Though for some reason, even on Debian, kdesu asks for my password instead of root's. If I try typing root's password, it tells me I gave it the wrong password. It works fine with my normal user password.
On Debian, as root, execute this to recover the default behaviour: cat > /etc/trinity/kdesurc << EOF [super-user-command] super-user-command=su EOF
On Saturday 26 November 2011 02:38:55 pm Timothy Pearson wrote:
What are the trinity executables that really need to run with sudo?
As an example, anything that needs root access in kcontrol. Some users also like to use sudo to launch a root-permissioned kwrite or konqueror.
(I have no /opt/trinity/sbin and apps in /opt/trinity/bin may be run with sudo `which ...`.)
Yes, but is this with the stock sudo? I would be very surprised if that were true.
Normal sudo can be run with any program. I can do 'sudo ls' 'sudo find' or 'sudo cat'.
On Saturday 26 November 2011 02:33:59 pm Laurent Dard wrote:
Le 26/11/2011 19:31, Timothy Pearson a écrit :
I don't think sudo should be a dependency.
It only is a dependency on distributions that use sudo in their core packages such as Ubuntu.
Also, why does trinity have it's own sudo? I'd think it should be able to find it in $PATH?
Look up the sudo RPATH "feature". Basically if the application is not present in /usr/bin or a handful of other hardcoded directories sudo won't find it.
What are the trinity executables that really need to run with sudo?
(I have no /opt/trinity/sbin and apps in /opt/trinity/bin may be run with sudo `which ...`.)
What come to mind right away are some of the kdeadmin stuff, such as KUser, which lets you add/remove/modify users and groups.
I'm sure there are others, but I can't think of them right now.
Le 26/11/2011 22:52, Kristopher John Gamrat a écrit :
On Saturday 26 November 2011 02:33:59 pm Laurent Dard wrote:
What are the trinity executables that really need to run with sudo?
...
What come to mind right away are some of the kdeadmin stuff, such as KUser, which lets you add/remove/modify users and groups.
Thanks.
It runs with the solution I just applied: Debian's sudo, with secure_path defined in /etc/sudoers.
Le 26/11/2011 17:30, Kristopher John Gamrat a écrit :
On Saturday 26 November 2011 11:15:19 am Calvin Morrison wrote:
Hello,
I think another thing on all of our minds should be towards dealing with the problems related to sudo. As we know not all distros support it, and also removing sudo in cases can remove the entire trinity install, wreak havoc and other terrible things.
Do we have a plan for this? Tim what needs to be done?
Some people don't even use sudo, and not all distros use it, even if they have it installed by default.
I don't think sudo should be a dependency.
Also, why does trinity have it's own sudo? I'd think it should be able to find it in $PATH?
I agree with you and I have no answers to your questions. I saw it's needed because of a problem with the path but I don't fully understand. I tried Debian defaults in /etc/sudoers: Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" without noticing problems.
Maybe trinity could only change /etc/sudoers (with debconf), adding: Defaults secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/opt/trinity/bin:/usr/bin:/opt/trinity/sbin:/sbin:/bin:/usr/X11R6/bin if it's really important.
Or maybe it could install its own version of sudo in /opt/trinity/bin, with a different configuration file (/etc/sudoers-trinity, for example), without conflicting with the installed one.
Does somebody knows what can be done to test sudo installation?
-
Calvin Morrison -
Kristopher John Gamrat -
Laurent Dard -
Lisi -
Robert Xu -
Timothy Pearson