[BUG] waagent is not cleaning up /etc/sudoers.d/*
- Dominant language
- Python
- Stars
- 581
- Forks
- 397
- Avg merge
- 2d 15h
- Merged PRs (30d)
- 9
Description
My team creates hardened Linux images on Azure using Packer. A cleanup provisioner is used to clean up the unprivileged user with `/usr/sbin/waagent`. After creating a hardened image, the unprivileged user is cleaned up but it is still in a sudoers config file. Although the user has been cleaned up, it's exposure to keep the user in the sudoers config file - an administrator might recreate the user for some reason without realizing that the user is automatically going to have passwordless sudo access.
I'm honestly not clear on what creates the unprivileged user and creates `/etc/sudoers.d/90-cloud-init-users`.
See below for a more full example.
**Distro and WALinuxAgent details**
WALinuxAgent-2.14.0.1
Python 3.12.13
Goal state agent 2.15.2.1
AlmaLinux 10.2
Packer 1.16.0
Note: we build various distro. Alma Linux 10 is not the only distro and they all leave the user in /etc/suders.d/*
**Additional context**
Simple steps to recreate without hardening:
1. Packer files:
```
$ cat minimal.pkr.hcl
locals {
managed_image_name = "CL9-1855-${ formatdate("YYYY-MM-DD.hh.mm.ss", timestamp()) }"
}
source "azure-arm" "foo" {
skip_create_image = false
use_azure_cli_auth = true
os_type = "Linux"
image_publisher = "almalinux"
image_offer = "almalinux-x86_64"
image_sku = "10-gen2"
vm_size = "Standard_DS1_v2"
# location = "eastus"
build_resource_group_name = "MY_GROUP_NAME"
managed_image_name = "${local.managed_image_name}"
managed_image_resource_group_name = "MY_GROUP_NAME"
private_virtual_network_with_public_ip = true
virtual_network_name = "MY_NETWORK"
virtual_network_subnet_name = "MY_SUBNET"
ssh_username = "packer"
ssh_private_key_file = "/home/jpfuntne/.ssh/id_rsa"
shared_image_gallery_destination {
storage_account_type = "Premium_LRS"
}
}
build {
description = "Minimal Azure builder"
sources = ["source.azure-arm.foo"]
provisioner "shell" {
script = "cleanup.sh"
pause_before = "2s"
timeout = "10s"
skip_clean = true
execute_command = "sudo -S -E sh -eux '{{.Path}}'"
}
}
$ cat cleanup.sh
#!/bin/sh -x
/usr/sbin/waagent -force -deprovision+user
$
```
2. Created the image with `packer build minimal.pkr.hcl`
3. Created an instance
4. Logged in and examined the system:
```
$ ssh azureuser@172.174.104.45
Last login: Tue Aug 18 15:18:44 2026 from 151.186.182.211
[azureuser@pfuntner-cl9-1855 ~]$ sudo -i
[root@pfuntner-cl9-1855 ~]# id packer
id: ‘packer’: no such user
[root@pfuntner-cl9-1855 ~]# grep -rw packer /etc
/etc/sudoers.d/90-cloud-init-users:# User rules for packer
/etc/sudoers.d/90-cloud-init-users:packer ALL=(ALL) NOPASSWD:ALL
[root@pfuntner-cl9-1855 ~]#
```
**Log file attached**
[waagent.log.txt](https://github.com/user-attachments/files/31186334/waagent.log.txt)
Contributor guide
Research direction
Start by reproducing the cleanup.sh flow with Packer and /usr/sbin/waagent -force -deprovision+user, then inspect the attached waagent log and /etc/sudoers.d/90-cloud-init-users. Trace how the unprivileged user and sudoers entry are created and removed; done means deprovisioning leaves no stale sudoers rule across the reported Linux distributions.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure, linux, python, shell
- Domain
- cloud, devops, operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100