If "AM" is read-only, suggest using "AppMan Mode" (for multiuser systems)

[ivan-hc]

Why?

Since the beginning, the rule has always been the same: the user who installed "AM" owns "AM, and with it all the contents of the /opt/am directory.

This results in constant error messages for other users of the system, whether privileged or not, like these:

Resume of our past attempts

In the past we have already tried to make "AM" more democratic, and to do so, we tried to compare the name of the owner of /opt/am with the one that used "AM", we even tried to change the permissions making all the content writable of /opt/am, to the detriment of security... all failed attempts!

What I've learned

But going back to the screenshot above, it is known that whatever user receives those error messages, it is definitely a user who does not have "write permissions" in /opt/am... and this is the focus of this PR .

Solution

We have an "AppMan Mode", which can be activated with the --user option, so... why not suggest to these excluded users to use "AM" as non-privileged users? Like "AppMan" indeed!

Examples

In the following examples I've already configured AppMan, so you will not see the prompt that appears when we need to configure it, this:

A common unprivileged user not in sudoers

This is the prompt for those who don't have write permissions in /opt/am (choose Y or N, default is Y):

A privileged user without "write permissions" in /opt/am

This is the same for all users without write permissions in /opt/am (here is a privileged user without permissions in /opt/am):

The admin that owns "AM"

For the main admin (the one that have installed "AM") its different, to enable "AppMan Mode" its necessary to use the option --user, as always:

Update "AM" in "AppMan Mode"

The user that have installed "AM" is also the only one that can update the core script APP-MANAGER, other users are not allowed.

How I know that I'm in "AppMan Mode"?

The following message only appears to the owner of "AM"...

"AM" is running as "AppMan", use am --system to switch it back to "AM"

...for other users, the use of "AM" in "AppMan Mode" will be discounted.

Again, why all this?

It's all about consistency, we have to explain to the user without write permissions in /opt/am why he can't use "AM" normally, and give him a chance to use it.

What changes are been done?

You don't need to go to https://github.com/ivan-hc/AM/pull/626/files

The changes in the code are minimal, just this part of the code in APP-MANAGER

	elif [ ! -w /opt/am ]; then
		read -p " \"AM\" is read-only, want to use it in \"AppMan Mode\" (Y,n)? " yn
		case $yn in
		'N'|'n')
			exit 0;;
		'Y'|'y'|*)
			echo '--------------------------------------------------------------------------'
			echo " \"AppMan Mode\" enabled!" | tr a-z A-Z
			echo '--------------------------------------------------------------------------'
			_use_appman 1>/dev/null;;
		esac
	fi

this is the full condition to check if "AM" should be used in "AppMan Mode":

if [ "$AMCLI" == am ] 2>/dev/null; then
	if test -f "$APPMANCONFIG"/appman-mode; then
		case "$1" in
		'--system')
			_back_to_am
			;;
		''|*)
			if ! test -f "$APPMANCONFIG"/appman-config; then
				_appman_mode_enabled_message
			fi
			_appman
			AMCLIPATH="/opt/am/APP-MANAGER"
			;;
		esac
	elif [ ! -w /opt/am ]; then
		read -p " \"AM\" is read-only, want to use it in \"AppMan Mode\" (Y,n)? " yn
		case $yn in
		'N'|'n')
			exit 0;;
		'Y'|'y'|*)
			echo '--------------------------------------------------------------------------'
			echo " \"AppMan Mode\" enabled!" | tr a-z A-Z
			echo '--------------------------------------------------------------------------'
			_use_appman 1>/dev/null;;
		esac
	fi
fi

[ivan-hc]

@Samueru-sama your opinion on this PR

[Samueru-sama]

@Samueru-sama your opinion on this PR

I'm not a fan of a user owning directories in /opt/* but the pr itself is fine I guess.