A few, random files & folders missing user Read permission
 

In Mint 18.1, I stumbled on this issue when trying out Deja Dup on a system back up.
It generated a short list of random folders / files it couldn't BU. I quickly saw it was because those listed didn't have Read permission for Group or Others (only for Root- the owner).

But 1000's of other files (even for same app, same location) are root owned AND user account has Read permission.

1) Do these same files or folders lack user Read permission for other Linux users - especially Mint?

2) Any idea why these few random files (some are empty folders) either never had or lost Read permission for the user account? Most don't like sensitive data that users shouldn't even read.

Some I recognize have a common name with Mint updates. Far more updates did NOT cause loss of Read permission. User account has Read permission on almost all files & folders.

3) From updates history, some with common names to the list below, the update history "installed dates" don't necessarily match "last modified" date shown in the file mgr.

Didn't check every one in list below against update history; enough to see updates weren't the ONLY cause of permission change. Assuming these didn't *always* lack user Read permission.

10-04-2017
Files without user account Read permission:
/boot/System.map-4.4.0-53-generic
/etc/.pwd.lock
/etc/NetworkManager/system-connections/Wired connection 1
/etc/apparmor.d/cache/sbin.dhclient
/etc/apparmor.d/cache/usr.bin.freshclam
/etc/apparmor.d/cache/usr.sbin.clamd
/etc/apparmor.d/cache/usr.sbin.cups-browsed
/etc/apparmor.d/cache/usr.sbin.cupsd
/etc/apparmor.d/cache/usr.sbin.ippusbxd
/etc/apparmor.d/cache/usr.sbin.named
/etc/apparmor.d/cache/usr.sbin.ntpd
/etc/apparmor.d/cache/usr.sbin.vlcdump
/etc/bind/rndc.key
/etc/cups/classes.conf
/etc/cups/ppd/HP-OJ-Pro-8600.ppd
/etc/cups/ppd/HP-OJ-Pro-8600.ppd.O
/etc/cups/printers.conf
/etc/cups/printers.conf.O
/etc/cups/ssl
/etc/cups/subscriptions.conf
/etc/cups/subscriptions.conf.O
/etc/default/cacerts
/etc/group-
/etc/gshadow
/etc/gshadow-
/etc/gufw/Home.profile
/etc/gufw/Office.profile
/etc/gufw/Public.profile
/etc/gufw/gufw.cfg
/etc/passwd-
/etc/polkit-1/localauthority
/etc/ppp/chap-secrets
/etc/ppp/pap-secrets
/etc/security/opasswd
/etc/shadow
/etc/shadow-
/etc/ssl/private
/etc/subgid-
/etc/subuid-
/etc/sudoers
/etc/sudoers.d/README
/etc/sudoers.d/ctdb
/etc/sudoers.d/mintupdate
/etc/ufw/after.init
/etc/ufw/after.rules
/etc/ufw/after6.rules
/etc/ufw/before.init
/etc/ufw/before.rules
/etc/ufw/before6.rules
/etc/ufw/user.rules
/etc/ufw/user6.rules
/home/.Trash-0
/home/bill/.cache/dconf
/home/bill/.gvfs
/home/bill/.thunderbird/Crash Reports/LastCrash
/home/lost+found
/lost+found
/opt/.Trash-0
/opt/keepass/Plugins
/opt/keepass/XSL
/opt/lost+found
/opt/pdf-xchange-v/Languages
/opt/pdf-xchange-v/SearchProviders
/opt/picpick/language
/opt/picpick/resource
/root
/usr/lib/cups/backend/serial
/usr/local/lost+found
/var/.Trash-0
/var/backups/group.bak
/var/backups/gshadow.bak
/var/backups/passwd.bak
/var/backups/shadow.bak
/var/cache/apt/archives/lock
/var/cache/apt/archives/partial
/var/cache/cups
/var/cache/debconf/passwords.dat
/var/cache/ldconfig
/var/cache/samba/netsamlogon_cache.tdb
/var/cache/samba/printing/printers.tdb
/var/lib/NetworkManager/secret_key
/var/lib/apt/lists/lock
/var/lib/apt/lists/partial
/var/lib/clamav/mirrors.dat
/var/lib/colord/.cache
/var/lib/dpkg/lock
/var/lib/dpkg/triggers/Lock
/var/lib/mdm
/var/lib/mlocate/mlocate.db
/var/lib/polkit-1
/var/lib/samba/account_policy.tdb
/var/lib/samba/group_mapping.tdb
/var/lib/samba/private/msg.sock
/var/lib/samba/private/netlogon_creds_cli.tdb
/var/lib/samba/private/passdb.tdb
/var/lib/samba/private/randseed.tdb
/var/lib/samba/private/secrets.tdb
/var/lib/samba/registry.tdb
/var/lib/samba/share_info.tdb
/var/lib/samba/winbindd_cache.tdb
/var/lib/samba/winbindd_privileged
/var/lib/systemd/random-seed
/var/lib/udisks2
/var/lib/urandom/random-seed
/var/lib/ureadahead/home.pack
/var/lib/ureadahead/opt.pack
/var/lib/ureadahead/pack
/var/lib/ureadahead/var.pack
/var/log/ConsoleKit/history
/var/log/ConsoleKit/history.1
/var/log/ConsoleKit/history.2.gz
/var/log/ConsoleKit/history.3.gz
/var/log/ConsoleKit/history.4.gz
/var/log/ConsoleKit/history.5.gz
/var/log/ConsoleKit/history.6.gz
/var/log/btmp
/var/log/btmp.1
/var/log/installer/casper.log
/var/log/installer/debug
/var/log/installer/partman
/var/log/installer/syslog
/var/log/installer/version
/var/log/samba/cores
/var/log/speech-dispatcher
/var/log/upstart/apparmor.log.1.gz
/var/log/upstart/cgmanager.log.1.gz
/var/log/upstart/control-alt-delete.log.1.gz
/var/log/upstart/cups.log.1.gz
/var/log/upstart/dbus.log.1.gz
/var/log/upstart/mountall.log.1.gz
/var/log/upstart/rsyslog.log.1.gz
/var/log/upstart/thermald.log.1.gz
/var/log/upstart/udev.log.1.gz
/var/log/upstart/upstart-socket-bridge.log.1.gz
/var/log/upstart/upstart-udev-bridge.log.1.gz
/var/log/upstart/ureadahead-other.log.1.gz
/var/lost+found
/var/spool/anacron/cron.daily
/var/spool/anacron/cron.monthly
/var/spool/anacron/cron.weekly
/var/spool/cron/crontabs
/var/spool/cups
/var/spool/rsyslog

look at the parent directory, they are all on the system side, means root only permissions to change them some may and some may not have read permissions other than root.

hasn't this been discussed at length already?

how is this different from the issues described in your other thread?

even you yourself statedso why again?

Thanks.
Because this post isn't about Deja-dup. It's merely one of many tools that could show Root owned files & folders w/o user Read permissions.

Maybe several readers of this post could check a few entries from my list (if they exist on your machine) & post short comment.
1) if they're Root owned
2) if they have Read permission for Others (if Root owned).

My guess is, most would normally have user Read permission. And either I or something changed permissions. If I could find their original permissions, I'd change them back.
If anyone knows a way to check what changed permissions on files / folders, or the date & time permissions changed, I'd check some (maybe the info's in some log)?

Most on the list were modified (some way) - months after installing Mint or the apps.
For several on the list - probably affected by updates via Mint Updater, their Date Modified didn't match the update time or date. Though "update packages" can have files with varying modified dates.

No. I'm trying to find what caused a tiny number of files & folders to not have user Read permission or what's so special about these. Deja-dup isn't the issue.

BW-userx - true, most are root owned. For space, I deleted some Firefox & Thunderbird (installed in /opt) files w/o user Read permission. CrashReports & PendingPings.
Under Windows, those files have FULL permissions for everyone. Apparently only an unbelievably small number of all files & folders in Mint & all apps - are root owned that don't have user Read permission. Either they're very special, or "something" changed permissions.

Nearly all root owned files, folders in Linux have user Read Permission.
AFAIK, there's nothing "special" about the list entries compared to often very similar files in the same folder (say, conf files).

If just being a root owned .conf file in /etc, or 10's of 1000's of root owned files & folders in /var/cache or /var/lib or /opt is why the list entries don't have user Read permission, then there'd literally be 1000's on the list.

In /var/lib alone, there are > 13,000 items, & only ~ 75 don't have user Read permission? That doesn't seem incredibly odd?

UPDATE: "Date Modified" apparently doesn't include permissions. Using "sudo ls -lc <filename>" will show when permissions last changed on files or folders. It shows what they changed to, but not the before nor what changed them.
I checked several files from the list. Most had permissions changed long after I installed Mint (files that would be included in Mint). That indicates for quite a few, something changed original permissions. I'm guessing for some it was updates, intentionally or not .

One problem is, Update History doesn't go back very far. But the dates that some files' permissions were changed coincided w/ days I did updates.
Using ls -lc <filename>, if a file shows the change was TO: "-rw on Oct 19, 2017, it's a good bet that the file wasn't permission-less before & they added the -rw. More likely it was -rw-r or -rw-r--r before & changed to -rw. A couple I checked appeared to never have user Read permissions from Mint's installation time.

I found a few old bugs reports (yrs back) where things like HPLIP incorrectly changed permissions. So it's possible. I can't imagine what harm Linux / Mint thinks users reading a few files will cause, if they have no write / execute permission.

In that entire list, there are a few files, such as /boot/System.map-4.4.0-53-generic and the files in /var/spool/anacron, that stand out as being unnecessarily restricted. The rest are files and directories that contain, or could contain, sensitive information. For some, e.g. /etc/shadow, it is essential that read access is restricted. (You wouldn't want your web browser to be able to read /etc/shadow and upload the hashed passwords to someone who could then crack them offline.) Various log files can contain information that users might not want leaked to other users on a multiuser system. That may be unnecessarily restrictive if you're the sole user, but Linux was designed to support multiple users in a wide range of environments, and the default permissions reflect that.