Find the answer to your Linux question:
Results 1 to 5 of 5
I want to know how can i give privaleges to groups and take them away from others lets say i want a guest user group that can use any thing ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Linux User
    Join Date
    Apr 2003
    Location
    TEXAS
    Posts
    314

    help with groups


    I want to know how can i give privaleges to groups and take them away from others

    lets say i want a guest user group that can use any thing just not install or change anything

    also i want to quit chmoding stuff like cdrom and mixer

  2. #2
    Linux Guru
    Join Date
    Oct 2001
    Location
    Täby, Sweden
    Posts
    7,578
    Let's take an entire lecture on UNIX permissions and privileges.
    Groups and users don't have any privileges in themselves, the exception being the superuser (UID = 0). GID = 0 is insignificant, though. The only thing they affect is which files you can access, and how.
    Look at it like this: Each running process in the system has exactly one User ID (UID), one primary Group ID (GID), and zero or more auxiliary GIDs. Of course, a process that has UID 0 (root) can do just about anything, but don't mind that now. (In fact, there are several of each: the real, the effective, the saved, and the filesystem IDs. The filesystem IDs aren't important at all since they almost always are equal to the effective IDs, but I'll get back to you on the real, effective and saved later on)
    I don't know if you know it, but there is exactly one way to create a new process in UNIX (and hence also in Linux), and that through forking (technically, in Linux, you can also clone a process, but don't mind that). When a process forks, an exact copy of it is created, and both continue to run simultaneously (as much as that is possible with a single CPU). The only way of executing a new program is through exec, which means that the program in a process is "replaced" with a new program. So what essentially happens when you run "ls" in a shell is that the shell forks, and then the new shell execs /bin/ls.
    Please note the difference between a process and a program. A process is a data structure in the kernel, so to speak. It records the state of a task, its PID, UID, GIDs, and so on. A program is the actual code that gets executed. So when a process execs a new program, the process is still the same, while the program inside it gets exchanged.
    So how does this come into the picture? Well, when a process forks and/or execs, its UID and GIDs and pretty much all other information except the actual program remains intact. It's kind of important to know. Also, only a process running with UID = 0 is allowed to change its UID (there is the exception of the saved UID, but I'll get back to that later).
    So basically, when you log in, the login process (running as root) forks, sets the new UID and GIDs, and then execs the shell (in text mode, the X session for the X login manager). Once the UID is changed from root, there's really no way to change it back.
    Then, when you attempt to access a file, the process' UID and GIDs are compared to the file's permissions, UID and GID. I don't know how much you know about file permissions, so I'll go through that too.
    A file has one UID, one GID, three sets of permissions, and one set of special permissions. All the permissions together make up the file's "mode". The three sets of normal permissions each include the permission to read from the file (the read permission), to change the file (the write permission), and to exec the file (the execute permission). This what happens when you try to open or exec a file:
    First, the kernel checks if the process' UID equals the file's UID. If that's the case, the kernel uses the first set of permissions (the "owner" set). Then it checks if any of the process' GIDs equals the file's GID. If that's the case, the kernel uses the second set of permissions (the "group" set). If none of these applies, the kernel uses the third set (the "others" set). What the kernel does with the permissions is pretty obvious; if you want to read the file, it checks if you have read permission, if you want to write to it, it checks that you have write permission, and if you want to exec it, it checks for execute permission.
    The three special permission are the Set-UID (or SUID) permission, the Set-GID (or SGID) permission, and the sticky bit. The sticky bit is nowadays useless for normal files, but it has special meaning for directories: normally, you can only delete (or unlink, more properly) files from a directory if you have write access to the directory. If the directory has the sticky bit set, you must either have the same UID as the file you're attempting to unlink, or you must have the same UID as the directory.
    The SGID permission for files means that if you exec the file, the primary GID of the process will be set to the GID of the file. The SUID permission is the same, except it affects the UID. For directories, the SUID permssion has no effect at all, and the SGID permission makes all files that are created in the directory have the same GID as the directory.
    Note that the primary GID and the rest of 'em are almost always treated the same. The primary GID is different in the effect the it determines what GID files that the process creates will have, and it is what gets set by SGID files.
    This is where the real, effective and saved IDs come into play. When you exec a file that is either SUID or SGID, only the effective ID is set. The effective ID is the only one used by the kernel for checks agains file permissions. The real ID is essentially only used by the programs themselves. For example, if a SUID program wants to know who really exec'd it, it looks at the real UID (since the effective UID has been changed). The saved ID is a bit special. Essentially, it will differ from the effective one when a program with SUID or SGID has been executed, and that process will be allowed to change to that ID even if it isn't running as root. When it changed to the saved ID, the saved ID will change to the former effective ID, so that SUID and SGID programs can switch between the ID of the user who execed it and the ID it got from the SUID or SGID execution.
    One more thing though: when root changes its effective UID or GID, the real and saved IDs are also changed to that new ID.

    So to answer your questions:
    You don't need such a group. Almost all files are already protected from write access from anyone but root. The exceptions are /tmp and /var/tmp, and since many programs need to be able to access them, you will want to have it that way.

    What did you mean with chmoding cdrom and mixer? Are you doing that now?

  3. #3
    Linux User
    Join Date
    Apr 2003
    Location
    TEXAS
    Posts
    314

    chmoding

    what I did to get the cdrom and the mixer saw i could use themn with out being root

    chmod a+r cdrom or chmod 777 mixer

    i want to undo this and have to where only users with a group like sound can access these devices

  4. $spacer_open
    $spacer_close
  5. #4
    Linux Guru
    Join Date
    Oct 2001
    Location
    Täby, Sweden
    Posts
    7,578
    Oh, that's no problem. Just chmod them to 660, chown them to, say, root:mixer, and add your user to the mixer group.
    However, you might want to use the pam_console module instead. It automatically ensures that the logged in user has access to those files, and then removes those permissions when the user logs back out. Doesn't your distribution come with it?

  6. #5
    Linux User
    Join Date
    Apr 2003
    Location
    TEXAS
    Posts
    314

    Slack ware

    im using slackware 9.0 usually slackware doesnt come with any thing it doesnt need

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •