Unable to save read information in informant.dat
Opened this issue ยท 17 comments
On running informant read 0
on first use it returns the following error:
ERROR: Unable to save read information, please re-run with correct permissions to access "/var/cache/informant.dat".
Currently informant defaults to persisting information in /var/cache/informant.dat
which unless you change the permissions on require superuser privileges to access.
It should probably be switched to save in ~/.cache/
or somewhere similar so that it can run with normal user privileges. I feel like I had originally left it as defaulting to requiring superuser because it dealt with installing packages, and for that one would need superuser anyway. But requiring superuser just so the program can save in /var/cache/
is a bit much.
If you don't want to run with sudo
, you can use the --file <file>
option to specify a different location to persist information or just change the permissions on /var/cache/informant.dat
so that your user can access it (you likely need to create the file first).
I'll get around to changing the program so that it doesn't default to requiring superuser.
I remember the design choice for using /var/cache/informant.dat
.
I originally designed it this way because of having it run as a pacman hook. When pacman is running the hook it needs to access the information on what news items have been read, I felt that this wasn't an issue for this program because one would need superuser access to the system to run pacman updates anyway.
That said a useability improvement could be making a group for informant
and having the data file be owned by the group that way a user could add themselves to said group in order to have password-less access to the file.
That said a useability improvement could be making a group for informant and having the data file be owned by the group that way a user could add themselves to said group in order to have password-less access to the file.
Would you be open to a PR which creates such a group upon installing the package, and prompts the user to add themselves to it? Or, how about just making informant.dat
owned by wheel
?
@codeclem I would be interested in such a PR. The installation stuff is currently done in the PKGBUILD so you'd have to fork the git tree in the AUR for that.
I'd prefer adding an informant
group over wheel
because of principal of least privilege.
That said, with the activity on here today it looks like I have some work to do tonight. If you have time to do a PR before about 5pm EST then go for it, if not I'll include it in what I'm doing tonight.
As of the latest AUR version 0.1.0-2
you should be able to add your user to the "informant" group in order to avoid using sudo.
I have installed 0.2.1-2
from the AUR and there is no group called informant
.
I tried sudo usermod -a -G informant markus
which did not fail, but didn't seem to do anything either.
I still have the same error:
> informant read
ERROR: Unable to save read information, please re-run with correct permissions to access "/var/cache/informant.dat".
@markusressel: Did you re-login with your user after adding it to the informant
group? What's the output when you run groups <username>
?
The output of groups markus
does include informant
.
groups
however, does not.
I opened a new shell, but I did not log out from the X session completely nor did I restart, is that necessary?
For clarification: I tested this on a manjaro installation. I plan to switch all of my devices to a plain arch installation and already have it on others, but this is the device I have at hand right now and it is not a plain arch.
I opened a new shell, but I did not log out from the X session completely nor did I restart, is that necessary?
Yes, even if there are some hacky ways to avoid this it's the simplest solution to just completely log off the user once.
Changes of a user's groups only take effect when logging in (you can check by running id
) and if you are still within your X session every shell is spawned with the old group settings that were prevalent when you logged into the X session.
Thank you, after a relog it works.
I was using too much SSH I guess.
I fixed this issue by modifying /usr/bin/informant
and changed the FILE_DEFAULT
path to my home directory.
May I know why do you need to define informant
group and why don't you use ~/.cache/
folder?
The reason I recommend the informant
group instead of changing the default save location is because of the pacman hook functionality.
When the pacman runs the hook the script (unless I'm mistaken) will be executing as root (or at least as euid 0). It didn't seem appropriate to me for a system utility to have it's save data in a user directory.
Other than modifying the script after it's installed to hard code the user folder I didn't see a clean way to determine the user's home directory (as the hook would evaluate ~/.cache/
to /root/.cache/
not the user's home directory). Then when run standalone by the user informant
would have a separate save data from when it's run as a pacman hook, which in turn could cause pacman to prompt a user to re-read some news items.
It's a bit weird trying to figure out the default behavior of something like this, as it can run as a system utility (pacman hook) or standalone by a user. Should multi-user systems be considered? Are all users that would use informant
expected to have privileges to run pacman
to update the system? Currently using the informant
group I'm assuming that any user that will run informant
standalone understands they will modify the system state and thus effect the behavior of the pacman hook, if users don't want to modify the system state informant -f <file>
should be used instead.
If anyone has better recommendations for default behaviors, or finds I'm incorrect about something I'm open to changing it.
Personally I am fine with the informant
group and the current behavior.
#17 probably fixes this issue. I tested it with and without sudo
.
UPDATE:
In latest commit, user will be the owner of the file. So informant check
command doesn't need to run with sudo
as well.
@bradford-smith94 You can close my PR if you don't like the way I fixed it. I don't mind.
I think using sudo
for calling informant
is the ultimate way, However some maybe doesn't like it.
@b00f I'm not completely against your solution in #17, I'm sorry if any of my comments (or the time it takes me to get around to responding) may have given you that impression. In some ways I think the solution you submitted is better than what we currently have, for example if anyone is running a multi-user Arch system in which there are multiple people with permissions to update packages this would allow them to each save a separate copy of what news items have been read by default (without needing to use the file option).
There is one case which I think the current code handles better, if a user switches to root to update packages. I believe the solution in #17 would look for informant.dat
in /root/.cache/
and if the user had not been using informant
as root then this file would be empty.
I'm guessing that a single-user/single-admin system where the user may switch to root occasionally is a more common use case for Arch than a multi-user/multi-admin system, so I would lean more toward the current solution than #17
I'm not completely sure what the default behavior should be. I think informant
should be able to handle being run as a pacman
hook with sudo
and directly as root in a way that makes the most sense. Right now I think that is solved with putting the file in /var/
and using either sudo
or the informant
group when running not as root. Multi-user support currently only exists in the -f
file option, which will not work for the pacman
hook, and if enough people want better multi-user support I'm open to improving that.
None of the solutions can cover all the possibilities. But I can say most of the users are single-user/single-admin and they use sudo
to install packages. In this case #17 helps to call informant
with or without sudo
and read/check Arch news.
whatever you decide, I will respect your decision. As Ken Thompson said:
"When in doubt, use brute force"