Meaning of console group?
 

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.

TIA

Gregor

I don't understand. root is distinguished by being root; you as a normal user won't be root.


The 'console' group is likely just an historical leftover. I'd be inclined to just ignore it.

Can't say i've ever used it, but i would assume it's linked to any existing serial console / serial port interface access. (i may be wrong)

The only groups that are beneficial to a user are suggested when using the adduser script. On 14.2, those are:

The other groups aren't really intended for users and are either system groups or, as GazL mentioned, a historical leftover.

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 ...?

Gregor

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.

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.

BTW: It's round 06:42 hrs here. Kind of late :-)

Gregor

Ah, I'm understanding now.

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 ;)

Thanks for your answer! I think I'll have to get used to work with file/user permissions again. Haven't done that for a long time.

So, consider this topic solved - g'night!

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.

Lots of options really...

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.