[Bug 1945202] [NEW] Tar changes folder ownership when run under root

2021-09-27 Thread Zsolt Ero
Public bug reported:

I got locked out of my server via SSH, simply by extracting a tar file.
No matter how crazy it sounds, it is reproducible.

1. login as root
2. wget 
https://github.com/aristocratos/btop/releases/download/v1.0.9/btop-1.0.9-linux-x86_64.tbz`
3. tar -xjvf btop-1.0.9-linux-x86_64.tbz`

At this point the /root folder has ownership of user:user (1000:1000)
and the root is locked out from SSH login. I had to fix the server via
KVM.

auth.log contained the following:
"Authentication refused: bad ownership or modes for directory /root"

This seems to be a bug in tar, as the above behaviour doesn't happen when 
logged in under any non-root user.
With non-root users the directory does not change ownership. 
With root user, no matter where I extract the tar file, the directory changes 
ownership.

---

lsb_release -rd
Description:Ubuntu 18.04.6 LTS
Release:18.04

apt-cache policy tar
tar:
  Installed: 1.29b-2ubuntu0.2
  Candidate: 1.29b-2ubuntu0.2

** Affects: tar (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1945202

Title:
  Tar changes folder ownership when run under root

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


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 50093] Re: Some sysctls are ignored on boot

2019-02-14 Thread Zsolt Ero
I feel it's important to add that the very last comment (Stanley
Sisneros (stanley-sisneros) wrote on 2018-05-30) is wrong, and the right
workaround is by Tomasz Konefal (twkonefal-j) wrote on 2018-05-07.

That is, add this to crontab:
@reboot root sleep 5 && sysctl --system

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/50093

Title:
  Some sysctls are ignored on boot

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 50093] Re: Some sysctls are ignored on boot

2019-02-14 Thread Zsolt Ero
Actually, the line which works without specifying a PATH in a cron.d
file is the following:

@reboot root /bin/sleep 5 && /sbin/sysctl --system

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/50093

Title:
  Some sysctls are ignored on boot

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1645002] [NEW] ssh sessions are not cleanly terminated on shutdown/restart with systemd

2016-11-26 Thread Zsolt Ero
Public bug reported:

In Ubuntu 16.04, a "reboot" command does not terminate the ssh session.
This results in clients hanging, until timing out (sometimes as much as
120 seconds).

This also introduces bugs to all  orchestration / automation tools which work 
over SSH, since they cannot issue their reboot equivalent for Ubuntu 16.04 
hosts. For example, have a look at this issue for Fabric:
https://github.com/fabric/fabric/issues/1488

The exact same bug has been fixed in Debian in version openssh/1:7.2p2-6. 
There is a very detailed discussion in their bug tracker:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751636

** Affects: openssh (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1645002

Title:
  ssh sessions are not cleanly terminated on shutdown/restart with
  systemd

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs


[Bug 1644996] [NEW] logrotate config uses syslog group

2016-11-26 Thread Zsolt Ero
Public bug reported:

The default logrotate config uses the "syslog" group.

> # use the syslog group by default, since this is the owning group
> # of /var/log/syslog.
> su root syslog

This is not correct anymore since 16.04, because:

1. "syslog" group doesn't exist on a stock Ubuntu 16.04 system, it only gets 
installed via rsyslog
2. The owning group is actually "adm".

This results in logrotate terminating with the following error during
cron.daily run:


run-parts -v /etc/cron.daily
run-parts: executing /etc/cron.daily/logrotate
error: /etc/logrotate.conf:7 unknown group 'syslog'

And can be fixed by changing syslog to adm group.

This is not present when rsyslog is installed, but only because that package 
creates the syslog group. This is a common bug in lighter environments, like 
Docker, where syslog-ng is a common choice instead of rsyslog, like in this 
issue: 
https://github.com/phusion/baseimage-docker/issues/338

** Affects: logrotate (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1644996

Title:
  logrotate config uses syslog group

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs