Replace ".cache" references with the "$AMCACHEDIR" variable / added write control on installed app directories / conversion in functions of the processes to update apps and generate the options list #622
Conversation
Merge pull request #620 from ivan-hc/dev
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
|
@Samueru-sama as I've said in the discussion, all works without errors now:
Strange fact is that the lists are updatable for both admin and guest. Last and more important thing: we can't update the apps (as guest)! |
@Samueru-sama In fact, there are indeed problems of inconsistency:
|
|
This is why "AM" is for one system admin. Others can rely on the "AppMan mode". |
|
at this point, to solve the problem of viewing the installed versions and files, it would be sufficient to keep /opt/am/.cache as the working directory, and make it editable by both admins and guests. |
|
I've just tested the downgrade to from "dev" to "main" using the guest user and worked! All modules are been restored to the version in "main" and were been managed in /opt/am/.cache So the issue was the RW permissions of /opt/am/.cache |
|
Also tried to use |
|
Guest can't install anything... nor can update any installed app. |
|
Of corse, since I've update modules as guest from main to dev... the admin can't edit the modules, because the patch has not been implemented in APP-MANAGER from main... so now its all OK. |
|
So, its time to change the title of this PR. @Samueru-sama we have solved the issue of permissions on multiple accounta without having to touch the "$HOME"./cache directory. The 6.3.3 nightmare is a far memory. |
ivan-hc
changed the title
|
As I already said, the guest user will not be able to install applications if he has no privileges. This is normal. So the key point remains updating the apps, which is impossible if installed by a user other than the one who wants to update. @Samueru-sama do you think it's a flaw? I find it advantageous instead, in terms of safety. Strengthens the sense of the |
This 👆 Now we have solved another issue in " |
|
Even apps that update themselves refuse to update if you don't use them... I consider it a "loyalty reward"
|
- give downloaded scripts and created directories the right privileges for common use in multiuser systems - removed a non-essential function
Change permissions for all files and directories in /opt/am
|
I've tested the installer too, in VM I had to replace "main" with "dev" in the URL, buth I've left the downloading of the modules from "Main". Steps I've done:
So we have fixed this. |
|
In APP-MANAGER I had to specify the following command:
@Samueru-sama I'm using this in all my VMs (Fedora 40, Debian and Arch Linux), and I'm testing this change on the Debian VM using three different accounts, two privileged and one not. Of corse I'm using this right now on my main machine, in both AM and AppMan. |
|
At this point the "$CHACHEDIR" variable is unused. |
|
@Samueru-sama regarding the choice to call the variable "$AMCACHEDIR" instead of "$CACHEDIR", your variable is an excellent starting point for future implementations, I would leave it where it is. I like it the way it is. My variable instead is specific to a directory that has existed since the beginning of this project. I just want to know if I need to add anything else or if it is possible to merge this PR as it is. My test results are all posted, but if I missed something, I would really like your opinion on it before merging. Also because you have just merged one of your PRs with "dev". In the case of apps to be merged, I would be more inclined to make these types of requests directly in "main", as they do not cause conflicts with the work done in the CLI. I can't move forward without your confirmation. |
Yeah I've been noticing lately that every PR I was making to dev was intermediately being merged to main. I was doing it because I remember in one of my firsts PRs you told me to merge to dev instead. But ok from now on apps will go to main. Regarding this PR, I guess everything is ready then.
I see, other package managers like pacman use |
for example, I have "appman" in $HOME/.local/bin and all its files are in $HOME/.local/share/appman, this is why the option -f in "AM includes also "AM" and in AppMan does not includes it
these are my directories of AM and AppMan instead
as you can see, AppMan has not a "remove" script, this is because it is portable, so you can remove it by putting it in the thrash |
|
@Samueru-sama I just want your opinion about file permissions in /opt/am With the inclusion of the "AppMan" mode, any user could only manipulate the APP-MANAGER file. With this change they can also manipulate forms and lists. What do you think, does it matter? I ask because a user who shares his system with other users, could have a really asshole user who could modify something maliciously. Do you think this is a possible scenario? Would you share your system with an asshole user? PS: Regardless of who it is, if something like that were to happen to me... I'd break his legs. For sure. |
|
@Samueru-sama Last thing: this is a major change. How do you see it? From version 6.10 or from version 7? |
This way also sudoers only allows the user to update and do nothing else for example.
I don't think this is really that major, it's your call anyway. |
But permissions are common only in /opt/am, not for other apps |
|
However, the scenarios I outlined above do not appear to have occurred. It seems to me that Garuda Linux only has a "guest" account by default, but I could be wrong. |
Ok Ivan I will tell you one thing, recently there was a big drama with hyprland because the developer made it so that it wrote some files for a few miliseconds to https://www.youtube.com/watch?v=BPo-Xa_J1yE This created such a big drama, because it meant that another user could exploit that to insert malicious code, as hyprland was going to compile whatever was in If you ask me I think that drama was way overblown, but keep that in mind as it happen to us. |
|
What do you suggest we do? Isn't using /opt/am /.cache or $HOME/.cache the same thing anyway? The modules and APP-MANAGER are always updated by any user. As for APP-MANAGER, this already happened in "AppMan Mode". If we add it all up, the problem can be solved by preventing the use of "AppMan Mode" and allowing a single system administrator to use "AM", as before ex-6.3.3 |
Leave am owned by the root user and require sudo to use it, add a function that adds the sudoers rule to allow to update without password and that is it. However this cannot be done today or tomorrow, as we have to be careful to not push as breaking change like it happened before with the groups issue.
No because, $HOME/.cache can only be written to by the user of said $HOME, I cannot edit the $HOME of other users for example. If I'm not mistaken you said that
I'm really don't understand what AppMan has to do here sorry 😅 AppMan is meant to be run in $HOME, so I don't know what it has to do in /opt. |
As long as "AppMan Mode" exists, it is not possible.
I remind you of the versions issue https://github.com/ivan-hc/AM/releases/tag/6.8.2
See "AppMan Mode"
Have you ever tried to launch the command " Launch it, open the file APP-MANAGER and run the command APP-MANAGER is the only file of the "AM" installation involved in the "AppMan Mode". All other files are managed in the AppMan's dedicated directory, in your $HOME, included modules. This PR basically allows the (almost) complete use of files installed with "AM" and for "AM". That said, should I therefore close it definitively and completely close the "$CACHEDIR" discussion you proposed? If yes, you agree with me when I tell you that "AM" must be managed by a single system administrator. |
|
I have another idea about this, to point out to the user that he doesn't have write permissions in the directories that "AM" manages, so he couldn't download at least the modules. It is already too late for APP-MANAGER, as this mechanism is used in "AppMan Mode". |
as I did at a590ad4 with |
You are telling me that on appman mode, AppMan doesn't write to AMPATH in $HOME? Uh oh.
I thought that change meant that you didn't have to rename APP-MANAGER to appman anymore and everything else still worked the same. I don't use Also I don't understand what you changed exactly here, I thought you changed all instances of |
In APP-MANAGER there is a series of confirmations on the I think that at this point it is necessary to restore everything to its original state, changing only the ".cache" references... but I would add a message notifying that writing is impossible in some directories, as I did at a590ad4 |
Btw Ivan I'm very sorry, like I wanted to do this in the near future and you intermediately began doing this and caught me off guard and couldn't help much. |
|
Don't worry, I'll apply only the messages in APP-MANAGER and revert INSTALL to its original state. |
Revert changes of previous commit. The one that installs "AM" is the owner and manager of all its files.
ivan-hc
changed the title
|
In the end, this PR turned into a simple refactoring with the addition of a couple of apps. At least we have explored the discussion on permits. At this point I can also close the discussion as https://github.com/ivan-hc/AM/discussions/616 |
|
@Samueru-sama I have to recalibrate the shot, it is not possible to update APP-MANAGER from other accounts. So "AM" is safer than we thought. I would just like to find a way to avoid this crap in other accounts:
|
|
It is a problem that sooner or later we will have to face, leaving the rule "AM has only one admin" intact. |
In reference to https://github.com/ivan-hc/AM/discussions/616 and as previously announced, this change should allow more flexibility for "AM" when used on systems with multiple user accounts.
From an idea of @Samueru-sama