Questions about using the -su command

hello

I have a question while studying Solaris today.

I have a question while studying Solaris today.

I want to create a user named work and include the user of work in the oracle group so that only the oracle group can use the su - command, but I failed for a long time, so I write here.

to sum up

  1. Create work user
  2. Include work users in oracle groups
    3.su - Set the command to use oracle groups only

If you know, please explain.

The OS you use is Solaris 11.4 and please explain Solaris 10.

Thank you.

In Solaris 11.4, you can create a user named "work" and include the user in the "oracle" group by using the "useradd" and "usermod" commands.

To create the "work" user, you can use the following command:

Copy code

useradd -m -g oracle work

The "-m" option creates the user's home directory, and the "-g" option sets the primary group for the user to "oracle".

To include the "work" user in the "oracle" group, you can use the following command:

Copy code

usermod -G oracle work

This command adds the "work" user to the "oracle" group.

To set the "su" command to use the "oracle" group only, you can use the following command:

chmod 4750 /usr/bin/su

This command sets the setuid bit on the "su" command, which allows only the owner (root) and members of the "oracle" group to execute the command.

In Solaris 10, the process is mostly similar. You can use the "useradd" and "usermod" commands to create and include the user in the oracle group, but instead of using the chmod command you can use "chgrp" to change the group ownership of the /usr/bin/su file to oracle.

chgrp oracle /usr/bin/su chmod 4750 /usr/bin/su

Please note that these commands should be executed as the root user, otherwise you will need to use "sudo" to execute them. Also, you should be aware of the security implications of setting setuid on the su command and ensure that you are not breaking any other security policies of your organization.

Please do not modify /usr/bin/su !!
It belongs to the Solaris OS and any modification can break things.
The previous post gave a bad advice.

Of course running useradd and usermod is okay.

Solaris has got RBAC as a means to give privileges. It is so advanced that I have hardly understood it and never used it.
A bit simpler is sudo, and you will get great support on this forum from all the Linux guys.
Does your system have sudo installed?

Can you explain your requirement for the su - command?
Give an example, and who may run it?

4 Likes

Yes, I don't want to do it the way above.
This test is a test for what happens later.

I just want to change a specific group to root user using the su - command.

The su command can be run by any user.
It switches to a new user, root by default. It asks for the new user's password, unlesss the calling user is root.
What is your goal now? Prevent other users to run su ?

Hello,

There are one or two ways you could do this...but to be honest, I'm very hesitant to go in to the details of how, as frankly it's not a good idea to modify the behaviour of a system binary. As others have said, the intention of su is to allow any user account to switch to any other account, if the person running it knows the password for the account they are switching to.

That last point is probably the most important one: restricting the ability of users to switch to another account isn't as important as ensuring that users only know the passwords for the accounts that they are supposed to have access to. If a user on your system knows the password for another account, they can make use of it directly anyway, and don't need to bother going via su.

Leaving su open for global execution is not really a security risk, and is the default behaviour on many millions of UNIX and UNIX-style systems all over the world. Unless you know the password of the account you're switching to, there is no security risk here; and if you do, the security risk arises from the fact that you know the password, and not the fact that you're able to run su.

1 Like

The OP @sejong can simply copy su and experiment with modifying that.

cp /usr/bin/su /usr/bin/sutest

Now, @sejong can experiment on /usr/bin/sutext all you want without worrying about unforeseen consequences changing /usr/bin/su.

2 Likes

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.