Permissions and users, help!

Good night!

The user folder in user group properties is read-only and has no write permission, how do I proceed to give the user read/write permission to the user group? The same goes to the wheel group that is not present in the user folder of the group properties.
 
chmod is your tool.
You could do something as little as chmod u=rw if all you want is the user's ownership to change, not the group/other bits.

Wheel is not present? In the /etc/group file?
I don't understand the statement.
 
.... not the group/other bits.

Wheel is not present? In the /etc/group file?
I don't understand the statement.
What I want to give permission is to the user group in the user folder properties, and the wheel group is not as the number one option in the properties.
 
Yep, still having a hard time. I may need another coffee.

Let's make it easier. Show us a brief listing of the user folder. ls -Fl will suffice. Point out what you want.
 
I don't even understand your questions. To begin with: Unix calls them directories, not folders.

What are "user folders"? Do you mean home directories? It would be clearer if you give us the explicit path names of the things you are talking about, like "/home/adam" or "/usr/home/bob" or "/usr/local/bin/charlie".

What are "user group properties"? Both directories and files have a variety of attributes, among them the user and group (who owns them) and the permissions.

When you want to give read/write permissions to the "user group", what do you mean? Read permissions, or write permissions, or both? You can set read and write permissions independently. Please look up how the 9 permission bits in Unix work. And what do you mean by "user group" in that sentence? The user or the group?

What do you mean when you say that the "wheel group is not present in the user folder of the group properties"? If you are talking about a FreeBSD system, then the wheel group better be present (the first line in /etc/group, the list of all groups), or else nearly everything will break. But then, individual groups are not "present in folders". And I don't understand what it means for the group properties to have a user folder.

I have a hunch what is going on here: You are not using the command line, but a graphical file management tool (which you haven't told us about, so we don't even know what you are dealing with), and you are describing what you are seeing here. Communication would be easier if you explain these problems with command line tools, and the appropriate language used there. In Unix, command line is the "lingua franca"; GUI tools are an afterthought, and there are many different ones.
 
Yep, still having a hard time. I may need another coffee.

Let's make it easier. Show us a brief listing of the user folder. ls -Fl will suffice. Point out what you want.

Now it's like this and it's wrong to give permissions graphically. In the user folder properties I want the group user and wheel to be able to give read and write permissions.

Code:
User properties

General         Emblems            Permissions

Owner:       user-x

Access:           Read and write

Group:            user

Access:           Read only

Others:           Read only

Help                                             Close
 
OK, I'm beginning to understand you. But I'm not sure I'm understanding you correctly.

I have no idea where that output you showed there comes from. But it is pretty unambiguous what it means. You are looking at a file system object, such as a file or directory (there are a few others, but they are uncommon). Whatever tool put up that output is telling you the following:
  • This object is owned by a user whose name is "user-x". The permission bits for user access are allowing that they can read and write, but not execute.
  • This object is owned by a group whose name is "user". The permission bits for group access are allowing read, but not write or execute.
  • The permission bits for anyone else allow read, but not write or execute.
To understand this, you need to first know a few fundamentals. In Unix (which FreeBSD is one variant of), every file system object has a user who owns it, and a group who owns it. In typical textbook examples the users have names such as alice, bob, charlotte, david, eve, ... and the groups have names such as marketing, engineering, sales, ... One of the things that makes your example a little confusing is that the username here is "user-x", and the group name is "user".

The next thing to know is: any entity that uses the computer is known as a "process". And each process also has a user and one primary group (they also can have additional groups). To find out what your user and group(s) are, you can run the "id" command from a shell.

The permission system in Unix (access control to file system objects) works roughly as follows:
  • If the user of the current process is the same as the user who owns the object, then the three permission bits for "user access" apply. The three bits are <R>ead, <W>rite and e<X>ecute. So the first line in the list above is that the permission bits for user access must be "rw-" (the normal way to print them is to print the bits if allowed, and a dash if not allowed).
  • If the user doesn't match, then the system checks if the group of the current process matches the group that owns the file. Again, there are the same three permission bits, which in this case seem to be set to "r--".
  • Lastly, if neither user or group(s) matched, then we have three permission bits for "other", also known as "anyone else", which in our example also seem to be "r--".
  • In summary, the permission bits here are "rw-r--r--", which is the most common permission for files.
Now, what you want is the group "user" to also have write permission. From a command line, that's completely trivial: Just run the command "chmod g+w ..." on the object (replace ... with the name or full path of the object). I have no idea how to do this in your GUI tool. I would suggest that you read about the chmod command, and how permissions are encoded in there; in short: the "g+w" notation means set the w permission in the group triplet.

The other thing you want makes no sense in the normal Unix permission system. You want to also allow group "wheel" to write. There is simply no provision for a file system object to have TWO owning groups, and therefore two sets of permissions. You'll have to find a different way to get there. You can try doing things with all processes in certain groups having multiple groups, but that might have unintended side effects. You might instead allow *all* other processes to write (by setting "chmod o+w ..."), but that could be very dangerous, since now all other users (not just wheel) can write. You could simply ignore the problem, since most processes that are in the group wheel are also the root user, and root can do whatever it wants, the permissions don't even apply to it. You could instead learn about ACLs (access control list, a complicated way to express access permissions that extends the 3x3=9 permission bits), but ACLs are not implemented consistently on all systems and file systems, their inheritance properties are tricky, and they are hard to learn.

I think what we really have here is an XY problem, combined with a language barrier. You are asking us how to set permission bits, but you are not explaining what you are really trying to accomplish. Please explain the underlying problem. And please start using the common Unix language (referring to things as directories, permissions, ...); the term "folder" is a Microsoft-ism, and the way you explain granting permissions shows that you are thinking about these things backwards.
 
Well explained ralphbsz . I would counter though, that folder (in desktops which is 'obviously?' what the op is dealing with here) is now a very common term in all OSs for a directory.

I also encourage the OP to tell us what the problem is he/she is trying to solve. One step at a time.
 
... One of the things that makes your example a little confusing is that the username here is "user-x", and the group name is "user".

In the installation path of the base system, the user is added and then the system automatically tells you to enter the full user, i.e. the user's full name is user-x and is used as the description of the user accoun, example.

Code:
Add Users

Username: user
Full name: user-x
...... .......
...... .......
login group is user.  Invite  user into other groups? [ ]: wheel operator
...... .......
...... ........

Now, what you want is the group "user" to also have write permission. From a command line, that's completely trivial: Just run the command "chmod g+w ..." on the object (replace ... with the name or full path of the object).
I would like it this way, and that the user group has permissions on the user's folder properties to read, write and execute.


Code:
User properties

General         Emblems            Permissions

Owner:       user-x

Access:           Read and write

Group:            user

Access:           Read and write

Others:           Read only

Help                                             Close
 
perform a chmod 0674 on the user directory.
For example, assuming a root path for the user of /home/user-x:

Code:
chmod 0674 /home/user-x
This will change the /home/user-x directory/folder to look like this:
drw-rwxr--

This, however, only changes the top directory/folder. Any folders within will remain the same.

So, if user-x has a folder called "my_secrets", it will remain as drw-rw-r--

A brief explanation:
(forgetting about the d in drw-rwxr-- as that's outside of scope here)
The rwxrwxrwx portion of the file protection is made up of mnemonics 4, 2 and 1 respectively, each in groups of 3. One for the user/owner, one for the group and one for everyone else.

4 = r, 2 = w, 1 = x.
Together they add up to a value. In the example given, chmod 674, that translates to:
r (4) + w (2) = 6 for the user/owner
r (4) + w (2) + x (1) = 7 for the group called user.
r (4) = 4 for everyone else.

There are other ways to change the mode of protection, but I find this the easiest. chmod() manpage is a good read.
 
The user needs x on the directory or else they won't be able to cd into it. Your 674 is probably the weirdest directory permissions I've seen, a more sane directory permission is 0775 or 0770.
 
The user needs x on the directory or else they won't be able to cd into it. Your 674 is probably the weirdest directory permissions I've seen, a more sane directory permission is 0775 or 0770.
I was following OPs question as it has taken this long to get to this point. If he wants this then that's what I gave him; weird or not.
 
Back
Top