SlackwareThis Forum is for the discussion of Slackware Linux.
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.
Finally I found a thing that distinguishes Slackware from Debian!
Forgive me - I'm just kidding.
Moving from Debian to Slackware I stepped over some files belonging to gregor.ftp
So it seems that GID 50 belongs to ftp now - not 'staff'. After adding a staff group I saw there is a group called console. What is this group meant to be used for? Maybe it's the right one for me - I want to distinguish me as root from myself as a normal user.
Since I'm quite new to Slackware I don't want to change system files until I really know what I'm doing.
The only groups that are beneficial to a user are suggested when using the adduser script. On 14.2, those are:
Code:
users audio cdrom floppy plugdev video power netdev lp scanner
The other groups aren't really intended for users and are either system groups or, as GazL mentioned, a historical leftover.
Quote:
I want to distinguish me as root from myself as a normal user.
What do you mean by this? As GazL mentioned, root is intended to be its own account. And other users can be specified to have certain permissions, either with the use of groups or sudo. If you give more information on this, we may be able to suggest the "Slackware Way" (if there even is one for whatever you're desiring), but the "Slackware Way" certainly isn't the only way and we might be able to give you info to tweak and modify your system as desired.
Looks like didn't make clear what I'm thinking of.
Well, it is (was?) said that I shouldn't log in as root if I want to do a typical user's work (like using some office stuff, nothing system related). So I want some things to be writable for my "simple user account" but not for any other user. What I'm thinking of is something between a normal user and root. I thought of using a group other than 'user' (but not 'root'). Maybe I'm missing something ...?
So I want some things to be writable for my "simple user account" but not for any other user.
Is this more than just your home directory? Because that is only viewable by you and root (everything is viewable by root).
In addition, if you want your user to have a directory outside /home/ that is controlled by the user, you can create it with root, set the user:group using chown as root, and then set the proper permissions using chmod as the user.
Is this more than just your home directory? Because that is only viewable by you and root (everything is viewable by root).
...
Yes, e.g. there are things under /usr/local/bin that I want to be editable (its not about viewable) only by me, not any other user. But I don't want to use the root account for changing these files.
For example: A script that produces a fancy signature. I want that script to be writable for my user account but not for other users. I'm thinking of some kind of level 'between root and a normal user'.
Hm. Maybe I have to think that thing over. Adding $USER to the root group may be what I'm looking for.
What you'd probably want to do is create the file as root, chown it to $USER:users, then you can chmod it to 755 (read write execute for the owner, you, then read and execute for the group and all others). You could also create your own group (I wouldn't use an existing group for this) which you could assign to your user, then you could have root own the file, that group have rwx and all others would just have r-x (775)
Adding your user to the root group can have serious security implications and would probably be best to be avoided.
And it's 23:04 right now here, so it's kinda late too
Looks like didn't make clear what I'm thinking of.
Well, it is (was?) said that I shouldn't log in as root if I want to do a typical user's work (like using some office stuff, nothing system related). So I want some things to be writable for my "simple user account" but not for any other user. What I'm thinking of is something between a normal user and root. I thought of using a group other than 'user' (but not 'root'). Maybe I'm missing something ...?
Gregor
The "wheel" group is historically meant to be used for purposes like this.
I thought 'wheel' was pretty much just for controlling access to su/sudo on UNIX systems.
I know in the past on some UNIX the 'bin' user/group were used to permit binaries to be updated without the need for full superuser permissions, but because of the need for SUID/SGID executable that never really worked well, and you tend not to see it done these days.
Anyway, for the specific use case given by the op, I would be inclined to suggest that editing in-place is just a bad approach and that one should keep a master copy of the script (or whatever) elsewhere and su -c 'cp whatever /usr/local/bin/' as needed. This is what I do.
There's also sudoedit, and emacs has TRAMP which can allow you to edit files owned by another user, but as I mentioned, I'm not a fan of editing in-place.
He could also use default ACLs to permit his login to create change files in /usr/local/bin but that can get a little involved as ACLs aren't straight forward.
I simply created a group "admin" that I use for this purpose, with myself as the only member. There would be a problem with files that might be affected by updates, but I'm not using that GID with any such files.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.