informant
informant copied to clipboard
bradford-smith94
Unable to save read information in informant.dat
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.
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"