AntiX 17.3.1 doens't change configuration

[Moderator caprea]

Helpful

Up

0

::

Anonymous wrote:

it would not have occurred to me to use “gksu” to launch a shell script…

All the entries in antixcc.sh are launched by gksu, I couldn’t see the difference.

Edit: Ah, I see now, so I thought the problem was deeper, still learning.

• This reply was modified 4 years, 2 months ago by caprea.

[Forum Admin rokytnji]

Helpful

Up

0

::

OK. Just tried adding app killer to personal using terminal and gksu
Went through all the motions and hit the refresh button.
Update menu gui did it’s song and dance and said success.

No App Killer in Personal Menu. So I try restart icewm. No Joy. I know app killer is in main menu. This was just test.

What will fool you is every step taken in gui shows OK. Success.
Lastly. Tried Update Menu. Still no app killer showing up in personal.

HTH.

Sometimes I drive a crooked road to get my mind straight.
Not all who Wander are Lost.
I'm not outa place. I'm from outer space.

Linux Registered User # 475019
How to Search for AntiX solutions to your problems

[Moderator caprea]

Helpful

Up

0

::

Offtopic
Skidoo, I’m still confused. Could someone explain why gksu works for block-advert.sh and antixccslim.sh ?

[Forum Admin anticapitalista]

Helpful

Up

0

::

Anonymous wrote:

skidoo – app must be run as sudo from terminal

…but (OMG) the launchstring provided by antixcc.sh is, in fact, “gksu menu_manager.sh”

… and that is what I changed.
Updated control-centre will run sudo menu_manager.sh

Philosophers have interpreted the world in many ways; the point is to change it.

antiX with runit - leaner and meaner.

[Anonymous]

Helpful

Up

0

::

skidoo, I’m still confused. Could someone explain why gksu works for block-advert.sh and antixccslim.sh

I, too, am confused by the discrepancy
passing an identical commandstring through gksu, it fails if issued from terminal emulator command prompt
but succeeds when initiated via antixcc

man sudo

-H, –set-home
Request that the security policy set the HOME environment variable to the
home directory specified by the target user’s password database entry.
Depending on the policy, this may be the default behavior.
. . .
HOME
Set to the home directory of the target user when the -i or -H options are specified (gksu unconditionally specifies -H),
when the -s option is specified (it is not) and set_home is set in sudoers (it is not),
when always_set_home is enabled in sudoers (checked: it is not),
or when env_reset is enabled in sudoers (it is) and HOME is not present (it _IS_ present) in the env_keep list.

/etc/sudoers.d/antixers

Defaults env_keep += “RESTARTED HOME“

we should recheck whether placement of the env_keep line, within antixers file (vs within sudoers) is effective
checked: is effective, and takes effect immediately, is noticed immediately afterward when invoking sudo
( tested by adding MAIL to the antixers env_keep line, save edited file, sudo bash, echo $MAIL )

I don’t know/understand the validity of RESTARTED

man sudo | grep restarted
man sudoers | grep restarted
man sudo.conf | grep restarted
man sudo_plugin | grep restarted
man visudo | grep restarted

[Anonymous]

Helpful

Up

0

::

The antixers file contains some additional “cruft”:

%users ALL=(root) NOPASSWD: /usr/local/bin/update-default-desktop
^———- does not exist in antiX17 Full (outdated, or is this an optionally-installed item)
(i noticed the isolinux README file mentions update-default-desktop)

%users ALL=(root) NOPASSWD: /sbin/fdisk.distrib
^——— I had to “go look it up”
is outdated, and would only ever be seen if “gnu-fdisk” package was installed
.

%users ALL=(root) NOPASSWD: /usr/local/bin/persist-save
^——— an as-shipped “convenience” which AFAIK is undocumented and presents a vulnerability.
Unless toram boot option is selected and the boot device can be removed,
a bad actor (or scripted malware) has opportunity to permanently cement unknown/unwelcome
permanent changes to the live system by surreptitiously performing a perist-save operation.

%users ALL=(root) NOPASSWD: /usr/local/bin/persist-config
^——- presents an outright vulnerability ~~ ability to run root-permissioned arbitrary commands
Demonstration:

persist-config --mute --command "touch /etc/nasty_stuff"
persist-config --mute --command "ps_mem.py"

[Author]

Posts