I’ve been looking for a spot to make a suggestion to the SUSE developers to make a suggestions about yast, but that did not go so well. So I’ll make it here.
I want to switch my system over to OpenSUSE from Ubuntu (I like unity, and now that is dead, I want to get away from Ubuntu to something new). And so far I’ve have been installing it onto a VM for a wile. I really like Yast GUI program for witch is why I would like to switch to SUSE. But I noticed that the root user account was enabled and my account could not do any root stuff (updates, installs, etc). So I configured sudo to use zypper but it still ask for a root password for the GUI yast and the terminal yast works with my password. So with research I conclude that the root user can only run the yast GUI utility.
So I want to make the suggestion on selected users to run yast rather than the root being the only user to run yast.
Mostly this comes from the standpoint that the enabled root user is powerful and if someone where to guess the password to root, the control the whole system (not that bad for me, but for cooperation networks maybe) and should be disable for safe keepings. In addition to that its more convenient to select a handful of users to use yast GUI instead of sharing the root password in a cooperation networks. As with my research, there are others who are trying the same thing too.
So is there any way this could get to SUSE developers as a suggestion. I would just change yast source code, but I’m not that good of a programmer to do that.
Ubuntu and openSUSE have different ideas on how to handle these things.
I doubt that openSUSE is going to switch to the Ubuntu way of life (configuring sudoers, using the wheel group, maybe more).
I doubt also that the openSUSE users world would react favourable if all they are used to is not functioning anymore.
After all when all distros were the same, there would be no case for different distros.
BTW if you have a guessable root password, I recommend you to change that to a stronger one.
You can configure your ordinary User account as a member of the Wheel Group, which is apparently a standard, recommended configuration in CentOS… which I personally am very suspicious of but who am I as an individual with far less knowledge than the entire CentOS community?
well ok, I WOULD like to switch from Ubuntu to SUSE and personally I would like to see something like that in SUSE (guessed I won’t be liked in the SUSE community then . . lol). I though it would be easy to just use one password for yast instead of a root and user password. I mean if not that is there a way to configure yast to allow selected accounts to use yast instead of root alone.
I mean if thats a bad idea then maybe root only access by default is enabled then selected users can access (and make changes to) yast then…
Or is yast meant for professional IT and Ubuntu is for other purposes. I mean do I kinda have a point on the administrator group for yast modification than a shared root password.
Hi
Then do it, nothing stopping you to configure sudo how you like, run everything as root user if you want… it’s your system, no one is stopping you? The openSUSE developers/contributors et al. seem pretty happy working the way it does and leaving these choices to the end user and not pre-configured.
If you want guidance on how to do this then suggest you ask your specific queries in the appropriate Technical sub-forum
On 2017-10-23, Weezle <Weezle@no-mx.forums.microfocus.com> wrote:
> Or is yast meant for professional IT and Ubuntu is for other purposes. I
> mean do I kinda have a point on the administrator group for yast
> modification than a shared root password.
I think you misunderstand YaST. YaST is convenience toolkit that provides an intelligent highly interactive environment
that still effectively does little more than runs bash commands, packaging scripts, and configuration file modifications
for you without you having to resort to console (unless you’re running YaST from its ncurses interface). Many of these
functions (e.g. disk partitioning or bootloader management) are at the level you would want only root privileges to
perform. If you’re quite happy for sudoers to perform these tasks, then there really is no point having separate
security policies for sudoers and root. Alternatively if you want a configuration utility to provide different levels of
access for root and sudoers, then YaST is probably not your best choice.
As other people have stated, Yast is a complete system configuration tool. Allowing complete access to it via sudo defeats the point of sudo in the first place. OP mentions zypper in the first post. I suspect that OP really just desires allowing sudo access to /sbin/yast2 sw_single. I unfortunately have close to zero experience with sudo and its group so i am unable to offer the needed help to OP. I’m pretty sure they just want access to that module though. If anyone can help them allow access to that part of Yast, i think we may be able to solve this issue.
The problem for Linux is that its core security model is generally built on files and file permissions and doesn’t really have a security model that’s based on Users. When MSWindows was designed, this was one of its main innovations at the time, although earliest 32-bit MSWindows borrowed heavily from a number of *NIX OS, a shift was made to build a full-fledged security system focused mainly on Users instead of file permissions. So, although MSWindows has its own root account (Admin 500), it has an Administrator User Group which doesn’t really exist in Linux although several distros use the wheel group to approximate the same functionality.
You can experiment with using the wheel group to give your selected Users root access, but you do that at your own risk. Research and verify that is what you are willing to do, and assume the consequences. Remember that even in MSWindows, the Admin 500 account is now considered so sensitive that it’s hidden by default and ordinary Users are not given the tools to be given full membership in the Local Administrators Group, you really have to be technically proficient enough to even know that such things exist and to find the way to do these things. By using the wheel group, you are potentially making your machine much more vulnerable than a typical MSWindows, think about that.
But, if you are willing to set up network security, you might look into whether LDAP might be a workable solution.
Although I haven’t set up openLDAP to enable this kind of Admin Group management, I’ve configured AD which is similar enough to speculate that you can do what you want.
Unless you are managing a network of more than 5 Users or so, OpenLDAP may not be worth the effort and investment.
> When MSWindows was designed, this was one of its main innovations at the
> time, although earliest 32-bit MSWindows borrowed heavily from a number
> of *NIX OS, a shift was made to build a full-fledged security system
> focused mainly on Users instead of file permissions.
Arguably, that wasn’t a Microsoft innovation - other companies had been
doing that in network operating systems for years - Novell, Banyan,
Lantastic…
I remember managing user-based permissions in a NetWare bindery back in
8- and 16-bit desktop systems days.
Microsoft built their security models around those kinds of network/user-
based security models.
