You are not logged in.

tdd

Beginner

  • "tdd" started this thread

Posts: 2

Location: Paris, France

Occupation: IT College Dean of Dept.

  • Send private message

1

Monday, October 31st 2005, 10:31pm

kdialog's dcop references within sudo

Hi all,

I've been meaning to provide a simple UI over a command-line tool automation done with bash scripting, and some of the processing being possibly lengthy, I wanted to use a progressbar at times.

kdialog provides a --progressbar mode which works through DCOP references.

Although what's in the documentation works swell in regular mode, if I run my script via sudo (which I have to do since it requires root privileges and setuid'ing the script after making root:root its owner/group doesn't seem to cut it), it doesn't seem to work: I do get the reference, but attempting to use it, e.g. like this:

dcop $dcopRef setProgress 1

invariably returns a "object inaccessible" error.

I tried using various parameters on dcop, e.g. --all-sessions or --user proper_userid, but this doesn't help.

There are two things that could help me out here:
1) a way to make my command-line tool get its job done w/o root access (but that's another story, and that doesn't help me know DCOP issues better)
2) a way for DCOP references in my context to work within sudo!

Ideas, anyone?

Thanks!
Christophe Porteneuve aka TDD

anda_skoa

Professional

Posts: 1,273

Location: Graz, Austria

Occupation: Software Developer

  • Send private message

2

Wednesday, November 2nd 2005, 4:47pm

Can you try accessing a progress dialog that way manually?

Because I think it should work with the --user switch.

For example start such a progress dialog and then, as root, type
#> dcop -.-user username
and see if it is listed

Cheers,
_
Qt/KDE Developer
Debian User

tdd

Beginner

  • "tdd" started this thread

Posts: 2

Location: Paris, France

Occupation: IT College Dean of Dept.

  • Send private message

3

Wednesday, November 2nd 2005, 5:13pm

Nope, doesn't work

Hi,

I had first tried your suggestion the other way around, that is, creating it as root then dcop'ing it as a user. It doesn't work. I had tried it before, but FYI, here's what it does:

- if I try dcop --user root as is, I get a warning because it doesn't find /root/.ICEauthority.

- if I export ICEAUTHORITY to my user's profile (the one from which sudo was done, and sudo doesn't modify $HOME), then retry, dcop hangs.

Then, about your idea: creating it in userland, than accessing it as root. Of *course* it works, since sudo preserves $HOME and root is, well, root.

However, when the DCOPRef is created within a sudo'd script, the same script, still running, cannot access the DCOP ref.

I think DCOP fails to register the DCOPRef in the proper space, somehow. I just don't know the details...
Christophe Porteneuve aka TDD

This post has been edited 1 times, last edit by "tdd" (Nov 2nd 2005, 5:16pm)


anda_skoa

Professional

Posts: 1,273

Location: Graz, Austria

Occupation: Software Developer

  • Send private message

4

Thursday, November 3rd 2005, 1:27pm

If the other user is creating the dialog, it might have started its own KDE environment, at least the parts necessary for DCOP.

What is the value of DISPLAY in this case?

If it works with the dialog being created by the user and the DCOP call being issued from the other user, I guess this is the way to go.

Maybe you can use a wrapper script that first creates the dialog and then sudo's the other script.

Cheers,
_
Qt/KDE Developer
Debian User