Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I have an OpenSuse Tumbleweed system running but the question maybe affects other distros too: Is there a way to allow launching the package updater for certain users only ? I have lots of users who log in as guests with limited rights, but they all seem to be able to do the package updating.
for the 'other' category on the binary(ies). You could change the group to something useful that Suse uses to indicate administration rights other than root if that is convenient.
One caution about padeen's suggestion: check the current ownership and permissions of your package updater. It probably does not have root permissions but requires the user to have adequate permissions. Giving just any user permission to update the entire system would certainly be dangerous. So the idea of using a different existing group that has the permissions necessary and that new users are not automatically a member of or creating such a group is probably the way to go. Be sure users you do not want updating are not given sudo access. And, as padeen said, be sure the program(s) have group execution permission but not other execution (or read/write) permissions.
What rights, user and groups does your zypper have then?
All the guest are in a single group named "training". Thats all. They are not in users. So far I only told them not to launch the updater. However they get the "updates available" notification and can launch the updater to the point where the new packages are listed. I did not test whether they can go beyond that point and do the actual updating.
Distribution: openSuSE Tumbleweed-KDE, Mint 21, MX-21, Manjaro
Posts: 4,629
Rep:
Several misunderstandings here on both sides .
When you issue in a console the command "ls -la /usr/bin/zypper" you get an output like this:
"-rwxr-xr-x 1 root root 2903712 15. Jan 21:07 /usr/bin/zypper". You can see that owner and group is "root". That is what I meant.
But.
Your problem child is not zypper at all. It is a program I kick from my box first thing. I deem it nervy and I schedule my updating myself. And I forgot its name. Sorry. You'll have to look there for permissions, owners, groups etc.
Hi. Oldest linux had a /opt directory. And you can install new software under it. Only need to change options install of the package (rpm, deb, etc) to this directory, and put a chmod 775 or 777 to it. Then all the users can install packages under this 'auxiliar' directory and not change /usr files.
Have a nice day.
Your problem child is not zypper at all. It is a program I kick from my box first thing. I deem it nervy and I schedule my updating myself. And I forgot its name. Sorry. You'll have to look there for permissions, owners, groups etc.
I agree with this but you're not looking at traditional owner, group permissions here. The problem your dealing with here is the auto-updater with launches in the panel at startup. I believe the execute permissions on that application are set using linux acls( access control lists), not with your standard owner/group permissions. I noticed this when I restored an opensuse installation from a tar backup where the backup was made using tar without the --acls option so acl permissions were not preserved. The restored installation from that backup did not launch that infernal auto-updater.
Last edited by kilgoretrout; 01-30-2019 at 09:42 AM.
Distribution: openSuSE Tumbleweed-KDE, Mint 21, MX-21, Manjaro
Posts: 4,629
Rep:
Quote:
Originally Posted by kilgoretrout
... I believe the execute permissions on that application are set using linux acls( access control lists), not with your standard owner/group permissions. ...
Ooops, now that is something entirely new to me . Good, something to learn.
Now, how should one proceed utilizing the acls to achive the OP's goal?
The problem is you have to find the application responsible for the auto-updater before you can set the acl permissions on it per the instructions in the above article. Once you find that file, you check the acl permissions with:
Code:
# getfacl <file>
You can then remove execute permissions for a given user on that file with:
Code:
# setfacl -m "u:<username>:r--" <file>
Unfortunately, where that executable file resides is anything but clear in the opensuse documentation. I've never been able to find it myself but I haven't looked all that hard. I don't think it's zypper since I can't update from the command line using zypper except as root so there must be some intermediary app running with root privileges that calls zypper and that's probably the one that has acl permissions set to let ordinary users run it. It's very confusing as it may depend on which DE you are using as both KDE and Gnome have their own auto-updater apps. For KDE, that app will appear in the panel system tray when active. If you right click on the system tray and select "System Tray Settings", under "General" you can untick "Software Updates" and that should stop the KDE updater from launching. However, the user can set it back if they know what they're doing. You can probably do something similar in Gnome, but I'm not familiar with that DE. That may be adequate for your purposes.
Last edited by kilgoretrout; 01-31-2019 at 07:42 AM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.