Bug 76479 - running "lpadmin" as a regular user parks you in a neverending loop
running "lpadmin" as a regular user parks you in a neverending loop
Status: CLOSED CANTFIX
Product: Red Hat Linux
Classification: Retired
Component: cups (Show other bugs)
8.0
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Tim Waugh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-10-22 05:34 EDT by Robert P. J. Day
Modified: 2008-05-01 11:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-18 10:46:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Robert P. J. Day 2002-10-22 05:34:25 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830

Description of problem:
  as root, "lpadmin -d <printer>" allows the admin to set a
default printer, which is recorded in /etc/cups/printers.conf.

  if you run this command as a non-root user, it prompts you for the
user's password (not sure why), and just keeps prompting for
it over and over.  for me, neither ^c or ^\ will break the
input loop -- i have to drop the window.

  not sure what lpadmin is asking for the user password for,
but really, it should make a decision and do something.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.$ lpadmin -d <printer>      # as a regular user
2
3.
	

Actual Results:    a neverending loop, being prompted for your password

Expected Results:  not sure, just something finite would be nice.

Additional info:
Comment 1 Tim Waugh 2002-10-22 10:11:02 EDT
Er.. I don't see this.  rpm -V cups?
Comment 2 Robert P. J. Day 2002-10-22 10:32:12 EDT
hmmm ... while the original owner/group of some CUPS files are root/root,
they're now lp/sys in /etc/cups.  should this bother me?

in addition, i figured maybe i messed up the certs, so i deleted the 
file under /etc/cups/certs.  now, when i try to configure an existing
printer as root, i get prompted for the root password, then it works.

however, if i try the configuration as a regular user, again, i get
prompted for that user's password and get stuck in a neverending loop,
being re-prompted for it.  until i type in root's password, then the
command just hangs.

does that help?
Comment 3 Tim Waugh 2002-10-22 10:35:52 EDT
> hmmm ... while the original owner/group of some CUPS files are root/root,
> they're now lp/sys in /etc/cups.  should this bother me?

Please concentrate on one bug at a time.  You'll find that this is reported
elsewhere in bugzilla, and fixed in rawhide.

Back to this bug.  As a regular user, I don't have lpadmin in my path at all. 
How are you calling it?  What does 'type lpadmin' say?
Comment 4 Robert P. J. Day 2002-10-22 10:42:47 EDT
  sorry, i thought the owner/group stuff may have had an effect on
this bug.

  i specifically add /sbin and /usr/sbin to my search path, because
even as a regular user, i like to be able to run things like
"mount" and "ifconfig" for display purposes only, so i'm finding
lpadmin in /usr/sbin.

  if regular users are not supposed to run lpadmin, then it seems
lpadmin should say so immediately and exit, not sit there in an
endless loop.

  i do note that the man page for lpadmin states that the CUPS version
of lpadmin "may ask the user for an access password depending on the
printing system configuration."  if it's possible to give regular users
CUPS admin privileges, i haven't got to that part of the docs yet.
in any event, the endless loop still seems like a bug, not a feature.
Comment 5 Tim Waugh 2002-10-22 10:47:06 EDT
Oh, I see it.  '/usr/sbin/lpadmin -d foo'
Comment 6 giulioo 2002-11-08 13:35:40 EST
upstream explanation:
http://www.cups.org/newsgroups.php?s3953+gcups.general+v3961
"...First, just press ENTER (blank password) to dismiss the password
prompt under Linux.  Unlike other OS's, the glibc getpass() function
traps CTRL-C..."
Comment 7 Tim Waugh 2002-11-11 12:49:49 EST
This seems to miss the point---there is no indication to the user that they must
use a blank password to get back to a prompt, and there is no need to endlessly
prompt for a password.  A few times ought to be sufficient before giving up, I
think.
Comment 8 Bill Nottingham 2006-08-07 13:43:26 EDT
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still
running Red Hat Linux, you are strongly advised to upgrade to a
current Fedora Core release or Red Hat Enterprise Linux or comparable.
Some information on which option may be right for you is available at
http://www.redhat.com/rhel/migrate/redhatlinux/.

Red Hat apologizes that these issues have not been resolved yet. We do
want to make sure that no important bugs slip through the cracks.
Please check if this issue is still present in a current Fedora Core
release. If so, please change the product and version to match, and
check the box indicating that the requested information has been
provided. Note that any bug still open against Red Hat Linux on will be
closed as 'CANTFIX' on September 30, 2006. Thanks again for your help.
Comment 9 Bill Nottingham 2006-10-18 10:46:07 EDT
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still
running Red Hat Linux, you are strongly advised to upgrade to a
current Fedora Core release or Red Hat Enterprise Linux or comparable.
Some information on which option may be right for you is available at
http://www.redhat.com/rhel/migrate/redhatlinux/.

Closing as CANTFIX.

Note You need to log in before you can comment on or make changes to this bug.