[Touch-packages] [Bug 788167] Re: CUPS cannot print to Kerberos-authenticated SMB print queue

2019-11-13 Thread Thomas Schweikle
Same for Ubuntu 19.10 with cups 2.2.12

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to cups in Ubuntu.
https://bugs.launchpad.net/bugs/788167

Title:
  CUPS cannot print to Kerberos-authenticated SMB print queue

Status in cups package in Ubuntu:
  Confirmed
Status in Debian:
  Fix Released

Bug description:
  Binary package hint: cups

  That was investigated on maverick (cups 1.4.4) and natty (cups 1.4.6).

  CUPS in Ubuntu cannot authenticate using Kerberos to an SMB print
  queue, such as one in an Active Directory.  This is because the smb
  backend is being invoked as user lp, and this user cannot access the
  Kerberos credential cache of the user who submitted the job.  When
  trying to print, the job is held for authentication, and a dialog
  prompting for username/password is being shown.  On Windows (and
  possibly other OS), the user would not be prompted if he has a ticket
  in the Kerberos realm (ie, "logged on to the domain") he is trying to
  print to.

  The CUPS smb backend on Ubuntu is the smbspool binary provided by
  Samba.  When run as a user, it will pick the Kerberos credential cache
  by itself and authenticate seamlessly.  Otherwise, it will read the
  KRB5CCNAME environment variable and try to use that when possible.

  There is two possible solutions to that:

  - Invoke the smb backend as root and pass it the KRB5CCNAME
  environment variable pointing to the user's Kerberos credential cache.
  CUPS execute the backend as user lp if it is world-executable, which
  is currently the case on Ubuntu.  User lp do not have the permission
  to read  the user's credential cache, hence why the smb backend would
  need to be executed as root (by removing the world-executable bit).
  Also, CUPS does not currently set KRB5CCNAME before invoking the smb
  backend (see http://www.cups.org/str.php?L3847).

  - Execute smbspool as the user submitting the job.

  
  I presume we would have the same problem with other backend that would do 
Kerberos authentication, although I do not know of a specific one.  I have only 
tested and investigated with the smb backend.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/788167/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 788167] Re: CUPS cannot print to Kerberos-authenticated SMB print queue

2017-04-19 Thread Alfonso de Cala
Fix released in Debian?

Reading the bug report (https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=711341) they just closed it with a wontfix.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to cups in Ubuntu.
https://bugs.launchpad.net/bugs/788167

Title:
  CUPS cannot print to Kerberos-authenticated SMB print queue

Status in cups package in Ubuntu:
  Confirmed
Status in Debian:
  Fix Released

Bug description:
  Binary package hint: cups

  That was investigated on maverick (cups 1.4.4) and natty (cups 1.4.6).

  CUPS in Ubuntu cannot authenticate using Kerberos to an SMB print
  queue, such as one in an Active Directory.  This is because the smb
  backend is being invoked as user lp, and this user cannot access the
  Kerberos credential cache of the user who submitted the job.  When
  trying to print, the job is held for authentication, and a dialog
  prompting for username/password is being shown.  On Windows (and
  possibly other OS), the user would not be prompted if he has a ticket
  in the Kerberos realm (ie, "logged on to the domain") he is trying to
  print to.

  The CUPS smb backend on Ubuntu is the smbspool binary provided by
  Samba.  When run as a user, it will pick the Kerberos credential cache
  by itself and authenticate seamlessly.  Otherwise, it will read the
  KRB5CCNAME environment variable and try to use that when possible.

  There is two possible solutions to that:

  - Invoke the smb backend as root and pass it the KRB5CCNAME
  environment variable pointing to the user's Kerberos credential cache.
  CUPS execute the backend as user lp if it is world-executable, which
  is currently the case on Ubuntu.  User lp do not have the permission
  to read  the user's credential cache, hence why the smb backend would
  need to be executed as root (by removing the world-executable bit).
  Also, CUPS does not currently set KRB5CCNAME before invoking the smb
  backend (see http://www.cups.org/str.php?L3847).

  - Execute smbspool as the user submitting the job.

  
  I presume we would have the same problem with other backend that would do 
Kerberos authentication, although I do not know of a specific one.  I have only 
tested and investigated with the smb backend.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/788167/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 788167] Re: CUPS cannot print to Kerberos-authenticated SMB print queue

2017-03-09 Thread Bug Watch Updater
** Changed in: debian
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to cups in Ubuntu.
https://bugs.launchpad.net/bugs/788167

Title:
  CUPS cannot print to Kerberos-authenticated SMB print queue

Status in cups package in Ubuntu:
  Confirmed
Status in Debian:
  Fix Released

Bug description:
  Binary package hint: cups

  That was investigated on maverick (cups 1.4.4) and natty (cups 1.4.6).

  CUPS in Ubuntu cannot authenticate using Kerberos to an SMB print
  queue, such as one in an Active Directory.  This is because the smb
  backend is being invoked as user lp, and this user cannot access the
  Kerberos credential cache of the user who submitted the job.  When
  trying to print, the job is held for authentication, and a dialog
  prompting for username/password is being shown.  On Windows (and
  possibly other OS), the user would not be prompted if he has a ticket
  in the Kerberos realm (ie, "logged on to the domain") he is trying to
  print to.

  The CUPS smb backend on Ubuntu is the smbspool binary provided by
  Samba.  When run as a user, it will pick the Kerberos credential cache
  by itself and authenticate seamlessly.  Otherwise, it will read the
  KRB5CCNAME environment variable and try to use that when possible.

  There is two possible solutions to that:

  - Invoke the smb backend as root and pass it the KRB5CCNAME
  environment variable pointing to the user's Kerberos credential cache.
  CUPS execute the backend as user lp if it is world-executable, which
  is currently the case on Ubuntu.  User lp do not have the permission
  to read  the user's credential cache, hence why the smb backend would
  need to be executed as root (by removing the world-executable bit).
  Also, CUPS does not currently set KRB5CCNAME before invoking the smb
  backend (see http://www.cups.org/str.php?L3847).

  - Execute smbspool as the user submitting the job.

  
  I presume we would have the same problem with other backend that would do 
Kerberos authentication, although I do not know of a specific one.  I have only 
tested and investigated with the smb backend.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/788167/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 788167] Re: CUPS cannot print to Kerberos-authenticated SMB print queue

2017-01-11 Thread Bug Watch Updater
** Changed in: debian
   Status: Unknown => New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to cups in Ubuntu.
https://bugs.launchpad.net/bugs/788167

Title:
  CUPS cannot print to Kerberos-authenticated SMB print queue

Status in cups package in Ubuntu:
  Confirmed
Status in Debian:
  New

Bug description:
  Binary package hint: cups

  That was investigated on maverick (cups 1.4.4) and natty (cups 1.4.6).

  CUPS in Ubuntu cannot authenticate using Kerberos to an SMB print
  queue, such as one in an Active Directory.  This is because the smb
  backend is being invoked as user lp, and this user cannot access the
  Kerberos credential cache of the user who submitted the job.  When
  trying to print, the job is held for authentication, and a dialog
  prompting for username/password is being shown.  On Windows (and
  possibly other OS), the user would not be prompted if he has a ticket
  in the Kerberos realm (ie, "logged on to the domain") he is trying to
  print to.

  The CUPS smb backend on Ubuntu is the smbspool binary provided by
  Samba.  When run as a user, it will pick the Kerberos credential cache
  by itself and authenticate seamlessly.  Otherwise, it will read the
  KRB5CCNAME environment variable and try to use that when possible.

  There is two possible solutions to that:

  - Invoke the smb backend as root and pass it the KRB5CCNAME
  environment variable pointing to the user's Kerberos credential cache.
  CUPS execute the backend as user lp if it is world-executable, which
  is currently the case on Ubuntu.  User lp do not have the permission
  to read  the user's credential cache, hence why the smb backend would
  need to be executed as root (by removing the world-executable bit).
  Also, CUPS does not currently set KRB5CCNAME before invoking the smb
  backend (see http://www.cups.org/str.php?L3847).

  - Execute smbspool as the user submitting the job.

  
  I presume we would have the same problem with other backend that would do 
Kerberos authentication, although I do not know of a specific one.  I have only 
tested and investigated with the smb backend.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/788167/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 788167] Re: CUPS cannot print to Kerberos-authenticated SMB print queue

2017-01-11 Thread Keith Ward
** Bug watch added: Debian Bug tracker #711341
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711341

** Changed in: debian
   Importance: Undecided => Unknown

** Changed in: debian
   Status: New => Unknown

** Changed in: debian
 Remote watch: None => Debian Bug tracker #711341

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to cups in Ubuntu.
https://bugs.launchpad.net/bugs/788167

Title:
  CUPS cannot print to Kerberos-authenticated SMB print queue

Status in cups package in Ubuntu:
  Confirmed
Status in Debian:
  Unknown

Bug description:
  Binary package hint: cups

  That was investigated on maverick (cups 1.4.4) and natty (cups 1.4.6).

  CUPS in Ubuntu cannot authenticate using Kerberos to an SMB print
  queue, such as one in an Active Directory.  This is because the smb
  backend is being invoked as user lp, and this user cannot access the
  Kerberos credential cache of the user who submitted the job.  When
  trying to print, the job is held for authentication, and a dialog
  prompting for username/password is being shown.  On Windows (and
  possibly other OS), the user would not be prompted if he has a ticket
  in the Kerberos realm (ie, "logged on to the domain") he is trying to
  print to.

  The CUPS smb backend on Ubuntu is the smbspool binary provided by
  Samba.  When run as a user, it will pick the Kerberos credential cache
  by itself and authenticate seamlessly.  Otherwise, it will read the
  KRB5CCNAME environment variable and try to use that when possible.

  There is two possible solutions to that:

  - Invoke the smb backend as root and pass it the KRB5CCNAME
  environment variable pointing to the user's Kerberos credential cache.
  CUPS execute the backend as user lp if it is world-executable, which
  is currently the case on Ubuntu.  User lp do not have the permission
  to read  the user's credential cache, hence why the smb backend would
  need to be executed as root (by removing the world-executable bit).
  Also, CUPS does not currently set KRB5CCNAME before invoking the smb
  backend (see http://www.cups.org/str.php?L3847).

  - Execute smbspool as the user submitting the job.

  
  I presume we would have the same problem with other backend that would do 
Kerberos authentication, although I do not know of a specific one.  I have only 
tested and investigated with the smb backend.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/788167/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp