Lack support to gksu

[Otavio Salvador]

Binary package hint: system-config-printer

I'm doing the packaging for Debian using current Ubuntu source as basis and found that it currently lacks support for gksu while it's really need for Ubuntu and many other distributions to be able to use this properly.

I'd like to discuss what alternatives we have to workaround this bug or how difficult might to be add the need support on it.

TIA,

[Otavio Salvador (otavio)]

My initial idea might be add something on gconf that could change the way of privilage scale is handled and then starting a new instance of system-config-printer if the user provide the right gksu password.

It looks enough to most of scenarios I can think about. Comments?

[Jani Monoses (jani)]

hi,

can you detail what are the current problems that this will solve? thanks

[Otavio Salvador (otavio)]

Well, as Ubuntu, many Desktop target systems are currently using sudo and locking their root account. On this specific case you won't be able to change server permissions except if you add the user at lpadmin too.

My idea is to use gksu to ask the password and then start a new instance of s-c-p as root making possible to change the need server params and like.

[Jani Monoses (jani)]

Is adding to lpadmin not actually cleaner? Is is not recommended for some reason?
Are you sugesting s-c-p respawning itslef with gksu when trying to set server settings?
We have to see how the Fedora upstream maintainer handles this case.

[Otavio Salvador (otavio)]

Yes, it's an option but it's not good IMHO since you'd need to add every user that would be admin not only at sudo but also at lpadmin group too.

Yes, I'm suggesting it or something that provides the same fuctionality for enduser. Ideas?

[Tim Waugh (twaugh)]

I think there is a misunderstanding about how system-config-printer authenticates. It does not become the root user at any point. It uses libcups (the CUPS API) to communicate with the CUPS server using the IPP protocol. At connection time we specify which user we are connecting as (usually root). When authentication is needed for a request, libcups runs our callback to provide it with a password, and at that stage we put a dialog on the screen.

On Fedora we currently use consolehelper in addition to this, only to make use of the cached authentication credentials that the pam_timestamp module provides -- but I do not like having to run the entire application as root, and may well remove this in future. system-config-printer caches authentication credentials in the session already.

I don't understand what you mean by "add the user at lpadmin too" -- can you explain what you mean by that?

[Otavio Salvador (otavio)]

> I don't understand what you mean by "add the user at lpadmin too" -- can you explain what you mean by that?

On Debian and Ubuntu, there two type of users allowed to change CUPS admin options (share printers and like) by default. They are: root and members of lpadmin group.

Currently Ubuntu locks root user so you can't change to user by its password since it has no password set and it's locked down. It uses sudo to auth as root. (Jani, have I missed something here?). In this specific case, I haven't found a way to allow a user to be able to change printer options _without_ adding him/her to lpadmin group.

Iif root account weren't locked, we might provide root password but it's locked. I'd like to have a centralized place where I can say who has admin rights on this machine and then this specific person will have full control (usually allowing him/her to use sudo to move to root). My specific issue here is it won't work since I cannot "auth on sudo" on s-c-p.

I hope I was clear now. There's something not understood yet?

[Tim Waugh (twaugh)]

CUPS uses PAM for authentication. Perhaps there is some configuration of /etc/pam.d/cups that can help you?

[Otavio Salvador (otavio)]

What's your suggestion for it?

[Tim Waugh (twaugh)]

I don't know PAM very well, I have to admit.

Locking the root account seems in this instance to have decreased security: previously, libcups would have handled the authentication for us (using PAM) -- but now we have to run the whole application as root.

How do you currently use the http://localhost:631/ interface in that environment?

Basically it comes down to your policy choice: who precisely do you want to be able to perform administrative functions? Console users? Any users logged into the machine? Only users in particular groups? etc. Once we know the answer to that question, we can work out what the real solution is. I don't believe that gksu or consolehelper (usermode) is the way to go long-term.

Perhaps the answer will be some special handling of the root certificate in /etc/cups/certs/0 or something.

[Till Kamppeter (till-kamppeter)]

For me authentication works as expected in the current s-c-p (0.7.71) together with the current CUPS (1.2.12 or 1.3.0 RC2) using the current Gutsy packages. If I am a user in the lpadmin group I can do everything without being asked for a password, including the server configuration settings. If I connect to a Feisty machine using the "Goto Server" button (and the user name of a user who is in the "lpadmin" group of the Feisty box) I can see all printers, but I cannot configure anything or add printers. I get "client-error-forbidden". But if I add "allow @LOCAL" to the "/admin" and "/admin/conf" locations in the cupsd.conf on the Feisty box and restart CUPS, s-c-p asks me for password of the user when I do the first queue addition or printer configuration change. I cannot change the server configuration of the Feisty box though, because Feisty still uses the CUPS with non-root patches. These patches are given up in Gutsy. So CUPS and system-config-printer in Gutsy work perfectly well as foreseen by the upstream CUPS.

Note that I have done a little patch on s-c-p, as the upstream version is hard-coded to connect to CUPS with the user name "root" by default. The patch lets the user name of the user calling s-c-p being used, which is the most adequate for Ubuntu (or any other distros with locked root account).

Hint: If an unprivileged user is logged in on the desktop, you do not need to log him out to do printer administration, nore do you need to "su" to your account from the command line. Simply start s-c-p and then click "Goto Server" and choose "localhost" and your user name. You will be asked for your password when you submit your first change.

I think nothing needs to be done here, perhaps changing the button text "Goto Server" to "Server/Authentication" or so.

Closing as fixed.