nopass v6.0

Password-less Script Improvements – Release Notes

Date: 2026‑01‑13

Overview

This release significantly improves the safety, observability, and verification tooling around passwordless behavior in the Password-less project:

• Hardened PAM nullok detection to avoid lockouts and false positives.
• Removed dangerous automatic password deletion.
• Added unified PAM + SSH empty-password audits.
• Upgraded the standalone pam-nullok-check.sh helper with richer diagnostics.
• Improved documentation to match the new behavior.

---

1. PAM nullok Detection and Safety

1.1 Smarter can_system_accept_empty_passwords

The main script’s can_system_accept_empty_passwords() now:

• Scans /etc/pam.d once for auth ... pam_unix(.so) lines.
• Ignores commented lines.
• Treats the system as accepting empty passwords only if it finds at least one auth pam_unix(.so) line that:
  • Contains bare nullok,
  • Does not contain nullok_secure on the same line,
  • Is not commented out.

It does not fail just because nullok_secure exists somewhere else (e.g. /etc/pam.d/login for TTY logins). This avoids false negatives on systems that use nullok_secure for console but nullok for other stacks (such as system-auth, password-auth, or sssd-shadowutils).

1.2 Logging and Summary

verify_empty_password_status (and the helper scripts) now:

• Print each relevant pam_unix line tagged as either:
  • nullok (empty passwords accepted for that auth stack), or
  • nullok_secure (TTY-only empty passwords).
• Summarize per file where bare nullok and nullok_secure occur.
• Clearly state whether PAM as a whole appears willing to accept empty passwords.

This makes it much easier to understand which PAM stacks are truly passwordless-capable.

---

2. Removal of Automatic passwd -d Behavior

2.1 Deprecated --delete-passwd-on-polkit-fail

The previously dangerous option --delete-passwd-on-polkit-fail has been removed from the script’s behavior and from README usage:

• The script no longer calls passwd -d automatically under any circumstances.
• All flows that used to offer automatic password deletion are now replaced by warnings only.

2.2 New Guidance in maybe_delete_password_for_target_user

The maybe_delete_password_for_target_user() function is now a no-op + explanation:

• It informs the user when polkit JS rules might be unsupported (e.g. polkit ≥ 124 with no JS rules present).
• It explicitly states that the script will:
  • Not run passwd -d.
  • Not change any Unix password automatically.
• It tells users to:
  • Use --verify-pam-nullok and/or pam-nullok-check.sh to inspect PAM first.
  • If they still want an empty Unix password, run passwd -d <USER> manually, fully understanding the risk.

---

3. Unified PAM + SSH Empty-Password Audit

3.1 --verify-pam-nullok → Full Auth Audit

The CLI option --verify-pam-nullok now runs a combined PAM + SSH empty-password audit:

• Internally wired to the new verify_empty_password_status() function.
• No configuration changes are made; this is a read-only audit.

3.2 PAM Side: can_system_accept_empty_passwords

As described above, this function:

• Detects bare nullok (without nullok_secure on the same line).
• Interprets the presence of such lines as indication that at least one local login path can accept an empty Unix password.

3.3 SSH Side: check_sshd_config_allows_empty

New helper function:

• Prefers sshd -T where available (and only when run as root) to inspect the effective SSH configuration, including Include/Match handling.
• If sshd -T is available:
  • Returns true if permitemptypasswords yes appears in the test output.
  • Returns false if sshd -T succeeds and does not report permitemptypasswords yes.
• Fallback:
  • Recursively scans /etc/ssh/sshd_config and /etc/ssh/sshd_config.d/*.conf for:
    • PermitEmptyPasswords yes on non-comment lines.

This ensures the audit sees whether SSH would even consider allowing empty passwords.

3.4 Audit Summary Output

verify_empty_password_status now prints:

• PAM Status: SAFE or RISK (nullok present).

• SSH Status: SAFE or RISK (PermitEmptyPasswords yes).

• A final interpretation:

  • CRITICAL – both PAM and SSH allow empty passwords.
  • WARNING – PAM local path allows empty passwords, but SSH blocks them.
  • WARNING – SSH allows empty passwords, but PAM appears to reject them.
  • RESULT – both look safe (no empty-password path found).

This clarifies the local vs remote exposure in one shot.

---

4. Standalone Helper: pam-nullok-check.sh

The helper script has been heavily improved:

4.1 PAM Logic

• Single-pass scan of /etc/pam.d for auth ... pam_unix(.so) lines.
• Ignores commented lines.
• Tracks:
  • nullok without nullok_secure → local paths that accept empty passwords.
  • nullok_secure anywhere → TTY-only empty passwords.

4.2 SSH Logic

• Checks for SSH server presence and:
  • Uses sshd -T if available to locate permitemptypasswords yes.
  • Falls back to PermitEmptyPasswords yes grep in sshd_config and sshd_config.d.

4.3 Exit-Code Semantics

• Exit code 0 (SAFE) – no bare nullok in PAM, and no PermitEmptyPasswords yes in SSH.
• Exit code 1 (RISK) – at least one of PAM/SSH is capable of operating with empty passwords.

This makes the helper friendlier for CI and security pipelines (0 = clean, 1 = risk).

4.4 Clear User-Facing Messages

The script now explicitly spells out risk:

• For PAM:

  • “PAM RISK: Your system’s PAM configuration includes at least one auth pam_unix(.so) stack that will accept an EMPTY PASSWORD…”
  • “This means at least one local login path is technically capable of working with no Unix password set for the account.”

• For SSH:

  • “SSHD RISK: sshd_config is explicitly configured with PermitEmptyPasswords yes. Remote SSH logins could succeed with an EMPTY PASSWORD if PAM also allows it.”

• Overall:

  • If risk is found:
    RISK: Your system is currently CAPABLE of operating with EMPTY PASSWORDS for at least one path (PAM and/or SSH).
  • If safe:
    SAFE: Based on current PAM and SSH configuration, empty Unix passwords should NOT be accepted for logins by default.

The helper also prints an extra SUCCESS/FAIL style line with emojis for at-a-glance understanding:

• ✅ SUCCESS: This system CAN operate password-less for at least one login path...
• ❌ FAIL: This system CANNOT be used without a Unix password by default (which is safer).

---

5. Internal Flag Cleanup and Naming

Internally:

• The legacy flag verify_pam_nullok_only has been renamed to:

  verify_empty_pw_only=0

• The --verify-pam-nullok option now maps to:

  --verify-pam-nullok)
    # Historical name; now runs the combined PAM + SSH empty-password audit.
    verify_empty_pw_only=1
    shift
    ;;

• The early-exit block now checks the new internal flag:

  if [[ "verify_empty_pw_only" -eq 1 ]] then
    verify_empty_password_status
    exit 0
  fi

This matches the new semantics while preserving CLI compatibility.

---

6. README Documentation Updates

The README has been updated to match the new behavior:

• --verify-pam-nullok is documented as:

  Historical option name, now wired to a combined PAM + SSH empty-password audit…

• The “PAM nullok vs nullok_secure and empty passwords” section now explains:

  • nullok vs nullok_secure.
  • The heuristic used by can_system_accept_empty_passwords.
  • That --verify-pam-nullok:
    • Prints all relevant pam_unix lines.
    • Summarizes where nullok/nullok_secure are present.
    • Inspects SSH for PermitEmptyPasswords yes.
    • Produces a final PAM/SSH risk summary.

• Emphasizes that the script never deletes Unix passwords automatically anymore and that any passwd -d action must be taken manually after reviewing the audit output.

---

7. Summary

This release focuses on:

• Safety: No automatic password deletion; better nullok detection; explicit risk messaging.
• Visibility: Clear per-file summaries plus unified PAM + SSH audits.
• Correctness: Single-pass scanning, robust regex, and sshd -T integration for accurate SSH interpretation.
• Documentation: README and comments now accurately describe the improved behavior.

These changes make it much harder to accidentally lock yourself out or misinterpret the system’s ability to operate without passwords, while giving you powerful tools to audit and understand your auth stack.

nopass v5.1

more robust update. No changes funtionality!

nopass v5.0

Password-less Release Notes

Date: 2026-01-12

Overview

This release focuses on experimental desktop integration features and much stronger safety warnings around dangerous modes. It is still intended only for single-user, non-critical machines where you fully accept the risks.

New: Root Desktop Unlock (Experimental)

--root-unlock

Status: Experimental, KDE/Plasma + PipeWire focused, NOT recommended for normal use.

This standalone mode tweaks only the root account and then exits without touching normal passwordless sudo / polkit for your regular user. It is meant for cases where you insist on running an entire KDE session as root and still want working audio.

What it does in this mode:

• Ensures the root account is a member of several desktop / device groups (e.g. audio, video, input, render, tty, etc.) so a root GUI session can see ALSA/PipeWire devices.
• Updates /etc/pulse/client.conf so that both of the following are enforced:
  • autospawn = yes
  • allow-autospawn-for-root = yes
• Optionally un-mutes ALSA Master/PCM mixer controls using amixer and then persists the mixer state with alsactl store.
• Bridges root audio to the normal user’s PipeWire/PulseAudio server by exporting:
  • PULSE_SERVER=unix:/run/user/<UID>/pulse/native
  • XDG_RUNTIME_DIR=/run/user/0
  • DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/0/bus
    into the following files if present (or created):
  • /root/.bashrc
  • /root/.profile
  • /root/.zshrc
• Detects if the root account appears locked in /etc/shadow (password field begins with ! or *) and, only after explicit confirmation, attempts to unlock it via:
  • sudo passwd -u root

A small state file is written at:

• /etc/passwordless-fb-root-unlock.state

for use by the restore command.

Important:

• This has been designed and tested primarily on KDE Plasma + PipeWire.
• GNOME, XFCE, Hyprland, and other environments are not tested and may behave differently or break.
• Using --root-unlock implies you are comfortable running a full root GUI session and accept all associated security risks.

--root-unlock-restore

Companion command to undo as much of the above as possible. It uses the state file and timestamped backups created by --root-unlock.

What it attempts to restore:

• /etc/pulse/client.conf from the latest .bak.<timestamp> backup.
• /root/.config/pulse, /root/.config/pipewire, and /root/.local/state/wireplumber from the latest *.bak.<timestamp> directories.
• The previous linger state for root (enabled/disabled) and the prior pulseaudio.service enable/active state.
• Removal of the injected environment exports (and their comments) from:
  • /root/.bashrc
  • /root/.profile
  • /root/.zshrc
• Removal of any groups that --root-unlock recorded as newly added for root.

This is a best-effort undo, not a hard guarantee. If the state file or backups are missing or corrupted, some changes may not be fully reverted.

New: Root Account Lock Detection and Optional Unlock

In --root-unlock mode the script now:

• Reads root’s password field from /etc/shadow.
• Treats a leading ! or * as a locked account.
• If locked, prints clear warnings and prompts you whether to unlock.
• Only runs sudo passwd -u root when you explicitly confirm (or when --yes is set).
• Does nothing in --dry-run beyond logging what it would attempt.

This is intended to make it easier to log into a root GUI session when the distribution ships with a locked root account, while still requiring an explicit, informed decision.

Hardened: --full-file-permissions (EXPERIMENTAL, NOT READY FOR USE)

The --full-file-permissions mode is now clearly marked as experimental and not ready for normal use.

Behavior:

• Skips the normal passwordless sudo / polkit / group / PAM configuration and runs only a recursive ACL grant equivalent to:

  setfacl -R -m u:<TARGET_USER>:rwx /

• Uses find + setfacl with exclusions for pseudo-filesystems and some network/service directories to reduce the chance of catastrophic breakage.

• Shows detailed progress via pv, and a small sample of setfacl error messages at the end.

Additional warnings added in this release:

• Every time --full-file-permissions is used, the script prints multiple high-visibility warnings:

  • It is an experimental feature, work in progress.
  • It will attempt to grant rwx ACLs on most of /.
  • It is very likely to permanently break your system (networking, display, services, etc.).
  • It should only be used on throwaway test installs with offline backups, and by users who intentionally want to stress or break the system.

• The README now explicitly states that this mode is for experimentation only and that you should expect to need a full reinstall or offline repair after serious use.

Other Improvements

• Stronger, clearer runtime warnings for:
  • --root-unlock
  • --root-unlock-restore
  • --full-file-permissions
• Extended environment bridging for root shells across:
  • /root/.bashrc
  • /root/.profile
  • /root/.zshrc (if present)
• More robust state-file writing for --root-unlock so that multi-line systemctl diagnostics cannot corrupt the state file.

Known Limitations

• --root-unlock is only tested on openSUSE Tumbleweed + KDE Plasma + PipeWire in a single-user configuration.
• GNOME, XFCE, Hyprland, and other desktops are not tested. Audio, login flows, or session services may break.
• --full-file-permissions remains an experimental feature: treat it as a destructive testing tool, not a supported configuration step.

Final Notes

This project remains targeted at advanced users who are comfortable reading shell scripts, understand Linux permissions and ACLs, and are willing to accept the risk of data loss and system breakage.

If you are unsure whether you should use any of these new options, you probably should not use them yet.

nopass v4.0

Password-less – Release (2026-01-10)

This release captures all recent work on setup-passwordless-fb.sh, focusing on:

• safer, more transparent handling of the extremely dangerous --full-file-permissions mode
• better progress and error visibility during ACL application
• a periodic systemd service/timer for re-applying full ACLs
• GUI/desktop integration and safer behavior on modern distros

---

1. CLI and Options

---

New/updated flags:

• --full-file-permissions

  • Nuclear option that runs a recursive ACL grant equivalent to:
    • setfacl -R -m u:<TARGET_USER>:rwx /
  • Now wrapped with:
    • multiple warnings and explicit confirmation prompts
    • pv-based progress display with total item count and items/sec
    • a concise post-run summary including elapsed time and approximate throughput
    • compact sampling of ACL errors instead of a wall of stderr

• --install-full-file-permissions-service

  • Installs a systemd service + timer (passwordless-fb-fullacl.service / passwordless-fb-fullacl.timer) that periodically re-applies --full-file-permissions.
  • When invoked by itself, the script enters an installer-only mode:
    • asks for confirmation
    • writes or reuses /etc/passwordless-fb-fullacl.conf
    • generates service + timer units
    • runs systemctl daemon-reload and systemctl enable --now passwordless-fb-fullacl.timer
    • exits without touching sudoers, polkit, groups, or anything else

• --uninstall-full-file-permissions-service

  • Uninstalls the periodic ACL service and timer.
  • When invoked by itself, runs in an uninstaller-only mode:
    • asks for confirmation
    • disables and stops the timer if present
    • removes the .service, .timer, and /etc/passwordless-fb-fullacl.conf
    • runs systemctl daemon-reload
    • exits without modifying sudoers, polkit, or other configuration

Other options and behavior (passwordless sudo, polkit integration, --relax-mac, --all-groups, --delete-passwd-on-polkit-fail, --restore, --verify-only) remain as described in the README, but have been re-documented more thoroughly.

---

2. Full-file-permissions ACL Engine Improvements

---

The --full-file-permissions logic has been heavily refined:

• Dependency handling

  • When --full-file-permissions or the full-ACL systemd service is requested and pv is missing, the script now treats pv as a dependency and installs it via the detected package manager (e.g. zypper, dnf, apt, etc.), unless --no-install is supplied.

• Progress bar and throughput

  • Before running setfacl, the script counts how many filesystem entries will be processed:
    • prints [info] Found N items. Starting ACL application with progress bar...
  • Uses pv -l to show a live progress bar with:
    • current / total items
    • percentage
    • approximate items/sec
    • ETA
  • Measures elapsed time and prints a human-readable summary, e.g.:
    • [info] Successfully applied ACLs to approximately 234882 items in 42s (~5592 items/sec).

• Error capture and sampling

  • setfacl stderr is piped through a small filter and also tee’d to a temporary log.
  • Rather than dumping every error line, the script now:
    • extracts unique messages
    • prints up to 5 as [acl-error] ... so the user can see the types of failures (e.g. read‑only filesystems, unsupported ACLs, missing paths), without being overwhelmed.
  • This maintains visibility into problems while avoiding an unreadable wall of output.

• Non-fatal behavior

  • Even when some paths fail (common on /proc, /sys, read‑only mounts, etc.), the script:
    • records that ACL application had errors
    • surfaces a clear warning and the sample of error lines
    • continues with the rest of the script instead of bailing out mid-run

---

3. Desktop Notifications and UX

---

For --full-file-permissions runs (both interactive and via the systemd service), the script now provides optional desktop notifications when notify-send and a graphical session are available:

• Start notification

  • e.g. "Applying recursive ACLs on / for . This may take a while and can affect many files."

• Finish notification

  • On success: "ACL application on / for is complete. Full-file-permissions are now in effect."
  • On error: "ACL application on / for finished with some errors. Check terminal output if you care about 100% coverage."

The script makes a best-effort attempt to target the user’s D-Bus session bus when running as root (e.g. under systemd). If there is no GUI or notify-send is missing, notifications are quietly skipped.

---

4. Systemd Service + Timer (passwordless-fb-fullacl)

---

A new systemd-based mechanism allows re-applying full ACLs on a schedule.

• Configuration file: /etc/passwordless-fb-fullacl.conf

  • ACL_TARGET_USER:
    • user that should receive full-file-permissions ACLs
    • defaults to the invoking user at install time if not explicitly set
  • ACL_EXTRA_ARGS:
    • extra arguments passed to setup-passwordless-fb.sh when run from the service
    • defaults to --sudo-only --no-install --yes
  • ACL_ONCALENDAR:
    • systemd OnCalendar= expression controlling the schedule
    • defaults to daily, but can be set to hourly, Mon..Fri 02:00, etc.

• Service unit: passwordless-fb-fullacl.service

  • One-shot unit that runs the script approximately as:
    • ExecStart=/usr/bin/env bash /path/to/setup-passwordless-fb.sh --user <resolved-target> --full-file-permissions ${ACL_EXTRA_ARGS}
  • The <resolved-target> username is baked into the unit at install time to avoid set -u issues with unset environment variables.

• Timer unit: passwordless-fb-fullacl.timer

  • Triggers the service according to ACL_ONCALENDAR.
  • Enabled/started by the installer mode when --install-full-file-permissions-service is used on its own.

• Exclusive install/uninstall paths

  • --install-full-file-permissions-service alone:
    • confirmation -> write/reuse env file -> write units -> daemon-reload -> enable/now -> exit.
  • --uninstall-full-file-permissions-service alone:
    • confirmation -> disable/stop timer -> remove units + env -> daemon-reload -> exit.

---

5. KDE and PAM Integration

---

• KDE kdesu integration

  • On KDE/Plasma systems with kwriteconfig5, the script sets kdesu to use sudo instead of su:
    • kwriteconfig5 --file kdesurc --group super-user-command --key super-user-command sudo
  • This makes graphical "Run as root" dialogs follow the same passwordless sudo configuration as the terminal.

• PAM su for wheel users

  • If a PAM su/su-l service exists (or a vendor file is present that can be copied into /etc/pam.d), the script:
    • ensures a pam_wheel.so line exists with trust and group=wheel
    • makes su passwordless for users in the wheel group
    • does so in an idempotent, cross‑distro‑friendly way, with backups when overwriting

---

6. Safety, Idempotency, and Uninstall Notes

---

• Safety checks

  • Refuses to target root as the passwordless user.
  • Always uses visudo to validate sudoers fragments and the final /etc/sudoers.
  • Backs up key files (sudoers, polkit rules, PAM configs) with timestamped .bak.* suffixes when --force is used.

• Idempotency

  • Re-running the script:
    • does not re-add duplicate sudoers or PAM lines
    • skips rewriting sudoers/polkit configs when they already match the desired content
    • recognizes its own comments/markers and avoids stacking changes.

• Undo/rollback

  • Normal sudo/polkit/PAM changes can be reverted using:
    • removal of sudoers drop-ins
    • visudo edits and the .bak.* backups
    • removal of polkit .rules files
  • --full-file-permissions ACLs remain inherently hard to fully undo; in many cases, a reinstall is the only truly clean revert.

---

7. Documentation

---

README.md has been fully updated to match this release. It now includes:

• Detailed descriptions of all options, including --full-file-permissions, the systemd service installer/uninstaller, and the polkit/MAC-related flags.
• A long, explicit warning section explaining why --full-file-permissions is effectively a filesystem-wide superuser grant and why it is so difficult to revert.
• Examples for:
  • basic passwordless sudo setup
  • sudo + polkit configuration
  • dry-run preview mode
  • installing/uninstalling the full-ACL systemd service
• Notes on desktop integration (KDE kdesu, PAM su for wheel) and the new pv/notification-based UX for full-ACL runs.

-----------------------------------------...

nopass v3

Password-less – Release Notes

Unversioned changes (latest)

Script: setup-passwordless-fb.sh

• Improved PAM su integration for passwordless su via the wheel group:
  • Locates su/su-l PAM configs in /etc/pam.d or vendor files in /usr/lib/pam.d and creates local overrides when needed.
  • If a pam_wheel.so line already exists, only adds the trust option (without duplicating the line).
  • If no pam_wheel.so line exists, injects a single
    auth sufficient pam_wheel.so use_uid trust group=wheel
    line either immediately after the pam_rootok.so auth line (preferred) or near the top of the file as a fallback.
  • Changes are idempotent: re-running the script does not keep adding extra pam_wheel.so lines or trust flags.
• Tightened polkit detection for newer versions (e.g. polkit-1 124+):
  • Uses pkaction --version to detect newer polkit.
  • Scans common rules directories for existing JS .rules files containing polkit.addRule; if none are found, treats JS rules as "maybe unsupported".
• Added optional --delete-passwd-on-polkit-fail flag:
  • When JS rules look unsupported, and this flag is set, the script can offer to delete the local Unix password for the target user via sudo passwd -d <TARGET_USER> (with confirmation and full support for --dry-run).
• Verified the script passes a basic syntax check (bash -n).

Documentation: README.md

• Added a section “Why passwordless sudo / su and what this script is for” explaining the intended use case (single-user personal/lab machines, convenience over isolation, reproducible config).
• Expanded the feature and options sections to document:
  • PAM su passwordless behavior for wheel members and its idempotent, cross-distro design.
  • The --delete-passwd-on-polkit-fail flag and how it interacts with polkit detection.
  • The tightened polkit JS detection heuristics (version check + scan for existing JS rules).

These notes describe the current state after the latest edits to the script and README.

nopass v2.1

v2.1 – Experimental --full-file-permissions option

This release introduces an extremely dangerous, opt‑in capability to grant a single user full read/write/execute ACLs across the entire filesystem, alongside existing passwordless sudo/polkit configuration.

New

• --full-file-permissions flag
  • When enabled, the script will (after extra confirmation) run:

    sudo setfacl -R -m u:<TARGET_USER>:rwx /
    
    

give me realise note

Here’s a concise release note you can use, e.g. for vX.Y.Z:

---

Password-less setup-passwordless-fb.sh – Release Notes

New features

• --all-groups flag (extremely dangerous)

  • New opt-in flag --all-groups that:
    • Enumerates every group on the system via getent group.
    • Adds the target user to all groups they are not already a member of.
  • This nearly eliminates all group-based security boundaries between the user and:
    • System services and daemons.
    • Device nodes (disks, video, audio, input, etc.).
    • Logs, sockets, and various service data.
  • Fully documented in the README and clearly marked as extremely dangerous.

• Expanded curated privileged group set

  • In normal mode (without --all-groups), the script now ensures the target user is in a broader set of powerful groups, if they exist:
    • root, disk, wheel, systemd-journal, network, video, audio, input, render, kvm, tty, tape, shadow, kmem, adm.
  • The script checks each group with getent group and only attempts to add the user if the group is present on the system.
  • Re-running the script after installing additional packages/groups will add the user to any newly-present groups from this list.

Documentation and warning updates

• Mandatory reading disclaimer

  • Added a strong statement that users must read the entire README, including all warnings and option descriptions, before running the script.
  • Explicitly states that running the script without understanding it makes any damage or compromise entirely the user’s responsibility.

• High-risk behavior section

  • New “High‑risk behaviors and options (read this first)” section near the top of the README that:
    • Lists all powerful groups the script can add the user to.
    • Explains that the script only adds the user to groups that actually exist, but will include new ones if they appear later and the script is re-run.
    • Summarizes dangerous options:
      • --relax-mac (weakens AppArmor/SELinux).
      • --full-file-permissions (recursive ACL u:<TARGET_USER>:rwx /).
      • --all-groups (member of every group).

• --all-groups option docs

  • Detailed description of --all-groups in the Options section:
    • Clarifies that it uses getent group.
    • Emphasizes that it effectively turns the user into a “member of everything” and that reinstalling the system may be the only safe rollback if something breaks.

Internal / safety checks

• Group existence checks

  • For the curated list of privileged groups, the script now uses getent group to verify that a group exists before calling usermod -aG.
  • Avoids errors on distributions where some of these groups are not defined.

• Syntax validation

  • Script validated with bash -n after changes to ensure there are no syntax errors.

nopass v2.0

# v2.0 – Stronger Warnings, Group Changes, and Docs Update

## ⚠️ Critical Security & Warranty Warning

This script is a **dangerous** convenience tool. It is intended only for advanced users who fully understand the risks.

- It can give the target user **root-equivalent power with no password**.
- It may add the user to highly privileged groups such as `root`, `disk`, `shadow`, and `kmem`.
- With these privileges, the user (or any process running as that user) can:
  - Run **any command as root** via `sudo` without a password.
  - Bypass many desktop/admin prompts via **polkit auto-approval**.
  - Access **raw disks**, kernel interfaces, and **sensitive files** (including password hashes) even *without* `sudo`.

**If this account is ever compromised, you should assume full system compromise.**

This project and release are provided **“AS IS”**, **without any warranty** of any kind.  
I am the original author of the script** and make **no guarantees** about:

- Security
- Correctness
- Fitness for any particular purpose
- Suitability for your environment

By downloading, installing, or running this script, **you accept all risk**, including but not limited to:

- Data loss or corruption  
- Security breaches and privilege escalation  
- Service outages or downtime  
- Violations of policies, contracts, or laws in your environment  

If you do **not** fully understand or accept these risks, **do not install or run this script**.

---

## What’s New in This Release

### 1. Group Membership Changes

The script now, when configuring a user (not in `--restore` or `--verify-only` modes), attempts to ensure the target user is a member of several privileged groups:

- `root`
- `disk`
- `shadow`
- `kmem`

This is done via `usermod -aG <group> <user>` and is **idempotent** (it will not re-add if already present).

**Implications:**

- `disk`: potential access to raw block devices → can read/write disks directly.
- `shadow`: potential access to `/etc/shadow` → password hashes, credential material.
- `kmem` (where present): potential access to low-level kernel memory interfaces.

These additions **further increase** the power and risk of the target account.  
Use **only** on machines where this is acceptable and understood.

## v2.0 – Optional AppArmor/SELinux Relaxation

- Added a new **optional** flag `--relax-mac`:
  - Best-effort stops the **AppArmor** service at runtime (if present).
  - Best-effort sets **SELinux** to **permissive** at runtime (if present).
  - Always logs what it’s doing and still prompts for confirmation unless `--yes` is used.
- By default, **nothing changes** for AppArmor/SELinux; you must explicitly pass `--relax-mac`.
- This does not change UIDs, groups, or sudoers, but it **removes important security enforcement layers** 
- and makes any existing privileges more powerful. Use only if you fully understand and accept the risk.

## v2.0 – Optional AppArmor/SELinux Relaxation + MAC Status in Verify

- Added a new **optional** flag `--relax-mac`:
  - Best-effort stops the **AppArmor** service at runtime (if present).
  - Best-effort sets **SELinux** to **permissive** at runtime (if present).
  - Always logs what it’s doing and still prompts for confirmation unless `--yes` is used.
- `--verify` mode now also prints a **MAC status summary** (AppArmor present/active, SELinux mode).  
  No MAC changes are ever made in verify-only mode; it’s informational only.
- As before, this does not change UIDs, groups, or sudoers, but **relaxing MAC reduces system security** and makes any existing privileges more powerful. Use only if you fully understand and accept the risk.

### 2. Expanded README Security Section

`readme.md` has been updated with:

- Explicit **security warnings** and a **legal/warranty disclaimer**.
- Clear statements that:
  - The script can fully subvert normal protections like `sudo` prompts.
  - The user must assume full compromise if the target account is abused.
- Practical guidance on safer usage:
  - Restricting this to **single-user, non-critical systems**.
  - Being careful with **SSH/remote access**.
  - Using **strong login passwords** and, where possible, full disk encryption.
  - Avoiding execution of random/untrusted code under this powerful account.
  - Keeping backups of `/etc/sudoers`, `/etc/sudoers.d`, and polkit rules.

### 3. Documentation Clarifications

- Clarified what the script actually does with:
  - `/etc/sudoers.d/<user>-passwordless`
  - `/etc/sudoers`
  - `/etc/polkit-1/rules.d/00-allow-<user>-everything.rules`
- Emphasized that the script is **idempotent** and uses `visudo` checks and backups (when `--force` is used).

---

## Installation Warning

Before installing or running this version:

1. **Review the code** yourself.  
   Do not run any script you have not personally inspected and understood.

2. **Read the README security section carefully.**  
   If anything there is unclear, **stop** and do not use the script.

3. **Back up your configuration:**

   - `/etc/sudoers`
   - `/etc/sudoers.d/`
   - `/etc/polkit-1/rules.d/`

4. **Test in a disposable environment first** (VM, test machine).  
   Verify behavior and recovery before applying to anything you care about.

---

## How to Install (If You Accept the Risks)

```bash
git clone https://github.com/<your-username>/Password-less.git
cd Password-less
chmod +x setup-passwordless-fb.sh

Then run, for example (for the current user):

./setup-passwordless-fb.sh --yes --force

Or sudo-only, no polkit:

./setup-passwordless-fb.sh --sudo-only --yes --force

Again: If you are not 100% sure what this does, do not install or run it.

If you tell me your intended version number and repo URL, I can customize the header and commands exactly for your release.

nopass v1.0

This script safely configures passwordless sudo (and optionally polkit) for a single Linux user. It creates a dedicated sudoers.d drop-in and can also add a matching NOPASSWD line to /etc/sudoers, always validating changes with visudo and creating timestamped backups. The script is idempotent (re-runs don’t duplicate lines), supports multiple distros/package managers, and includes convenient modes to restore from backups and to verify that passwordless sudo/polkit are working without making further changes.