mcury
August 1, 2023, 11:24pm
1
Anyone got this message during the today’s update ?
[2023-08-01T20:08:46-0300] [ALPM] warning: directory permissions differ on /etc/credstore/
filesystem: 0 package: 700
[2023-08-01T20:08:46-0300] [ALPM] warning: directory permissions differ on /etc/credstore.encrypted/
filesystem: 0 package: 700
Should I worry about it ?
Thanks.
Edit : I suppose this is expected ?
https://raw.githubusercontent.com/systemd/systemd/main/NEWS
3 Likes
pebcak
August 1, 2023, 11:55pm
2
Check the permissions for /etc/credstore.
Mine is:
drwx------. 2 root root 4096 Jul 28 02:00 credstore
So it looks there is nothing to change/fix.
1 Like
mcury
August 1, 2023, 11:56pm
3
hmm, everything seems to be correct here then…
$ ls -lah /etc/ | grep cred
drwx------ 1 root root 0 abr 5 16:24 credstore
drwx------ 1 root root 0 abr 5 16:24 credstore.encrypted
Thanks pebcak
1 Like
So the right permissions are 700 ? Because mine are weird :
d--------- 2 root root 4096 4 avril 22:50 credstore
d--------- 2 root root 4096 4 avril 22:50 credstore.encrypted
and I didn’t find anything in the logs.
pebcak
August 2, 2023, 10:25am
5
If I am not mistaken, d---------
is equivalent to permision 000 meaning that nobody but root has rwx permisions.
I guess that would be the same as 700 when the owner is root anyways.
000 is not the kind of permission that is common.
Are we expected users to run the two following commands to correct the permissions?
sudo chmod 700 -R /etc/credstore/
sudo chmod 700 -R /etc/credstore.encrypted/
pycrk
August 2, 2023, 3:17pm
8
I can’t tell you with certainty, but the warning about permissions makes sense and they are not without reason. I’ve changed my permissions as in your example.
if you look at the history of the code, recently the permissions was changed from 000 to 700.
committed 09:03AM - 27 Jan 23 UTC
This adds a tmpfiles.d/ snippet for LoadCredential= style credentials
directorie… s in /etc/ and /run/.
This is done primarily to ensure that the access modes for the dirs are
set up properly, in the most restrictive ways. Specifically these are
set to 0000, so that CAP_DAC_OVERRIDE is necessary to enumerate and read
the credentials, and being UID=0 is not sufficient to do so.
This creates /etc/credstore/, but leaves /run/credstore/ absent if
missing, for now. Thinking is: the latter being non-persistent is
created by software usually, not manually by users, and hence more
likely right. But dunno, we might want to revisit this sooner or later.
This is ultimately an exercise to advertise the LoadCredential= concept
a bit, and do so in a reasonably secure way, underlining the safety of
the concept.
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
# See tmpfiles.d(5) for details
d /etc/credstore 0700 root root
d /etc/credstore.encrypted 0700 root root
z /run/credstore 0700 root root
z /run/credstore.encrypted 0700 root root
4 Likes
pebcak
August 2, 2023, 5:39pm
9
Since in my system the permissions for those directories were reported as 700, I just left it at that.
I have come across this one thread on Arch’s forum regarding this permissions issue: https://bbs.archlinux.org/viewtopic.php?id=287675
4 Likes
Yeah I saw that too, and was going to post the link this morning, but all that’s worth reading is this: “There’s nothing to fix. Check the directory permissions, that upgrade changed them.” People on the Arch Reddit are a bit still unsure what to do at the moment tho. I’d post the Reddit link, but looks like Reddit is currently down at the moment so…
system
Closed
August 4, 2023, 9:00pm
11
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.