** Description changed:

+ [Impact]
+ 
+ At the moment rsyslog cannot have access /dev/console due to a mismatch
+ permission/ownership between '/dev/console' and the Privilege Drop User
+ and Group 'syslog' in rsyslog.
+ 
+ [Test Case]
+ 
+ * Deploy focal/20.04LTS
+ * Install rsyslog
+ * systemctl restart rsyslog OR systemctl restart rsyslog
+ * Inspect /var/log/syslog for the following error:
+ syslog:Aug  4 14:37:56 <HOSTNAME> rsyslogd: file '/dev/console': open error: 
Permission denied [v8.2001.0 try https://www.rsyslog.com/e/2433 ]
+ 
+ [Regression potential]
+ 
+ https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1890177/comments/4
+ 
+ [Other information]
+ 
+ [Original description]
+ 
  The Privilege Drop options ($PrivDrop*) in focal's rsyslog both point to
  'syslog' for the user and group, and don't match the
  ownership/permission of '/dev/console' generating the following:
  
  syslog:Aug  3 15:16:58 <HOSTNAME> rsyslogd: file '/dev/console': open
  error: Permission denied [v8.2001.0 try https://www.rsyslog.com/e/2433 ]
  
  Looking in Bionic/18.04LTS, '/dev/console' used to be root:syslog[1],
  nowadays it's root:tty[2]
  
  [1] - Bionic/18.04LTS (Gcloud instance)
  # ls -l /dev/console
  crw--w---- 1 root syslog 5, 1 Aug  3 15:17 /dev/console
  
  [2] - Focal/20.04LTS (Gcloud instance)
  # ls -l /dev/console
  crw--w---- 1 root tty 5, 1 Aug  3 17:19 /dev/console
  
  # /etc/rsyslog.conf
  $PrivDropToUser syslog
  $PrivDropToGroup syslog
  
  ** As a debug exercise I did the following:
  - Cannot reproduce the situation if I intentionally get rid of the PrivDrop* 
options.
  - Cannot reproduce the situation if I intentionally add 'syslog' user member 
of 'tty' group.
  
  Meaning that it's pretty obvious with the above statement that the
  permission denied is caused by the permission/ownership mismatch between
  '/dev/console' 's ownership permission & syslog user
  (PrivDropTo[User|Group]).
  
  Other bug:
  https://github.com/GoogleCloudPlatform/compute-image-packages/issues/889

** Description changed:

  [Impact]
  
  At the moment rsyslog cannot have access /dev/console due to a mismatch
  permission/ownership between '/dev/console' and the Privilege Drop User
  and Group 'syslog' in rsyslog.
  
  [Test Case]
  
  * Deploy focal/20.04LTS
  * Install rsyslog
  * systemctl restart rsyslog OR systemctl restart rsyslog
  * Inspect /var/log/syslog for the following error:
  syslog:Aug  4 14:37:56 <HOSTNAME> rsyslogd: file '/dev/console': open error: 
Permission denied [v8.2001.0 try https://www.rsyslog.com/e/2433 ]
  
  [Regression potential]
  
  https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1890177/comments/4
  
  [Other information]
+ 
+ Other bug:
+ https://github.com/GoogleCloudPlatform/compute-image-packages/issues/889
  
  [Original description]
  
  The Privilege Drop options ($PrivDrop*) in focal's rsyslog both point to
  'syslog' for the user and group, and don't match the
  ownership/permission of '/dev/console' generating the following:
  
  syslog:Aug  3 15:16:58 <HOSTNAME> rsyslogd: file '/dev/console': open
  error: Permission denied [v8.2001.0 try https://www.rsyslog.com/e/2433 ]
  
  Looking in Bionic/18.04LTS, '/dev/console' used to be root:syslog[1],
  nowadays it's root:tty[2]
  
  [1] - Bionic/18.04LTS (Gcloud instance)
  # ls -l /dev/console
  crw--w---- 1 root syslog 5, 1 Aug  3 15:17 /dev/console
  
  [2] - Focal/20.04LTS (Gcloud instance)
  # ls -l /dev/console
  crw--w---- 1 root tty 5, 1 Aug  3 17:19 /dev/console
  
  # /etc/rsyslog.conf
  $PrivDropToUser syslog
  $PrivDropToGroup syslog
  
  ** As a debug exercise I did the following:
  - Cannot reproduce the situation if I intentionally get rid of the PrivDrop* 
options.
  - Cannot reproduce the situation if I intentionally add 'syslog' user member 
of 'tty' group.
  
  Meaning that it's pretty obvious with the above statement that the
  permission denied is caused by the permission/ownership mismatch between
  '/dev/console' 's ownership permission & syslog user
  (PrivDropTo[User|Group]).
  
  Other bug:
  https://github.com/GoogleCloudPlatform/compute-image-packages/issues/889

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

Title:
  rsyslogd: file '/dev/console': open error: Permission denied

Status in rsyslog package in Ubuntu:
  New
Status in rsyslog source package in Focal:
  In Progress

Bug description:
  [Impact]

  At the moment rsyslog cannot have access /dev/console due to a
  mismatch permission/ownership between '/dev/console' and the Privilege
  Drop User and Group 'syslog' in rsyslog.

  [Test Case]

  * Deploy focal/20.04LTS
  * Install rsyslog
  * systemctl restart rsyslog OR systemctl restart rsyslog
  * Inspect /var/log/syslog for the following error:
  syslog:Aug  4 14:37:56 <HOSTNAME> rsyslogd: file '/dev/console': open error: 
Permission denied [v8.2001.0 try https://www.rsyslog.com/e/2433 ]

  [Regression potential]

  https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1890177/comments/4

  [Other information]

  Other bug:
  https://github.com/GoogleCloudPlatform/compute-image-packages/issues/889

  [Original description]

  The Privilege Drop options ($PrivDrop*) in focal's rsyslog both point
  to 'syslog' for the user and group, and don't match the
  ownership/permission of '/dev/console' generating the following:

  syslog:Aug  3 15:16:58 <HOSTNAME> rsyslogd: file '/dev/console': open
  error: Permission denied [v8.2001.0 try https://www.rsyslog.com/e/2433
  ]

  Looking in Bionic/18.04LTS, '/dev/console' used to be root:syslog[1],
  nowadays it's root:tty[2]

  [1] - Bionic/18.04LTS (Gcloud instance)
  # ls -l /dev/console
  crw--w---- 1 root syslog 5, 1 Aug  3 15:17 /dev/console

  [2] - Focal/20.04LTS (Gcloud instance)
  # ls -l /dev/console
  crw--w---- 1 root tty 5, 1 Aug  3 17:19 /dev/console

  # /etc/rsyslog.conf
  $PrivDropToUser syslog
  $PrivDropToGroup syslog

  ** As a debug exercise I did the following:
  - Cannot reproduce the situation if I intentionally get rid of the PrivDrop* 
options.
  - Cannot reproduce the situation if I intentionally add 'syslog' user member 
of 'tty' group.

  Meaning that it's pretty obvious with the above statement that the
  permission denied is caused by the permission/ownership mismatch
  between '/dev/console' 's ownership permission & syslog user
  (PrivDropTo[User|Group]).

  Other bug:
  https://github.com/GoogleCloudPlatform/compute-image-packages/issues/889

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1890177/+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

Reply via email to