<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Backup on ShieldedBytes</title>
    <link>https://linuxeries.org/tags/backup/</link>
    <description>Recent content in Backup on ShieldedBytes</description>
    <generator>Hugo</generator>
    <language>en</language>
    <lastBuildDate>Mon, 19 Oct 2026 09:36:02 +0200</lastBuildDate>
    <atom:link href="https://linuxeries.org/tags/backup/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>How to Give the Backup User Read‑Only Access to /var/log via ACLs Without Granting sudo</title>
      <link>https://linuxeries.org/post/2026-10-19-how-to-give-the-backup-user-readonly-access-t/</link>
      <pubDate>Mon, 19 Oct 2026 09:36:02 +0200</pubDate>
      <guid>https://linuxeries.org/post/2026-10-19-how-to-give-the-backup-user-readonly-access-t/</guid>
      <description>&lt;h2 id=&#34;acls-for-logonly-access&#34;&gt;ACLs for log‑only access&lt;/h2&gt;&#xA;&lt;p&gt;When you need a user to read system logs but you don’t want to give them sudo or pull them into a privileged group, POSIX ACLs are the cleanest way to do it.&lt;br&gt;&#xA;They let you hand out read rights on a per‑file or per‑directory basis, and you can set defaults so that every new file inherits the same restrictions.&lt;/p&gt;&#xA;&lt;p&gt;A backup account that pulls logs to an off‑site archive but never touches the live system is the classic case. ACLs keep the principle of least privilege intact while still letting the job run unattended.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
