Not sure exactly what your question is. Can you be more specific? Specifically, I'm having difficulty parsing
I want a /home/shared where raul &
ricardo have permission over this
folder, maybe www-data and root, but
any other user on any linux distro.
Do you want to know how to set up a shared folder/partition? If so, you could just set up a group in each installation with the same group id. Then perhaps use acl to make sure group has rw
permission to the partition.
man addgroup
says
A GID will be chosen from the range
specified for system GIDS in the
configuration file (FIRST_GID,
LAST_GID). To override that mechanism
you can give
the GID using the --gid option.
So you could do
addgroup [options] [--gid ID] group
where group
and ID
is the same in both installations.
For a tutorial about acl see Using ACLs with Fedora Core 2, and see my answer to a recent question about sharing a directory between two users. Obviously, you'll need to mount the partition with acl support on both installations.
Once acl
is set up, all files and directories in the folder will have group permissions rw
and so raul
from one installation and ricardo
from the other installation will both be able to read and write to that folder.
EDIT: In response to raul's comment below:
If I understand your question correctly, and you are trying to share data between two www-data
users on two installations, then this a slightly different question
than the one you seemed to be asked with raul
and ricardo
, because in this case, the users would be the same.
www-data
would be typically created by a web server installation like apache, so creating them with matching ids would be difficult unless it was already the case (see below). I think there should be no problem in altering the uids/gids after the event to match, but I'm not 100% sure about that. Perhaps the experts here can advise.
Note that Debian defaults to uid/gid=33
for www
. It is possible it would not be the same for other Linux distributions. However, if your installations were both the same distribution, the ids would very likely match. Indeed, if this were the case, you could just use the www-data group as your group, and you would not have to do anything.
You are thinking that the !
, *
or x
has a special meaning here, and are therefore worrying that there might be some distinction among them.
The fact is that these characters are chosen simply because they stand out, at least to Western eyes. These characters connote a missing value, or an exception case, or a warning. You could put boogabooga
here and have exactly the same effect.
This is because of the way passwords are handled on Unix type systems. When the system receives a password entry, it hashes it and compares it to the stored hash. Therefore, all that matters here is that you use some character or sequence of characters that cannot possibly be a valid password hash. (It also mustn't include a colon, for obvious reasons.)
Though there is no difference between these characters from the core OS's perspective, there are some conventions:
When the Linux pwconv(8)
program sees x
, it takes that to mean "I have already moved this public password hash to the shadow password file."
That's not an important case in practice because the days of converting to (or, heaven help you, from) shadow passwords are behind us now.
If you use usermod -L
or passwd -l
to lock a user, !
has special meaning in /etc/shadow
because that's the convention for "break this hash so it doesn't match any more."
Adding any other character to the stored hash would break it just as well. Violating this convention merely prevents usermod -U
or passwd -u
from unlocking the user's login. Just as equally true, since you locked it by hand by adding a bogus character, you can unlock it by hand by removing it.
All that is just trivia with respect to this question, however. There is no groupmod -L
or gpasswd -l
, hence no !
convention in /etc/group
.
More trivia: if you are going to lock user accounts by hand, you should stay away from the [A-Za-z0-9/\]
set, since those are legal characters for the hash. That's one reason usermod
uses !
here instead of x
.
I don't see anything wrong with normalizing all your /etc/group
password fields, if that makes you feel better. By doing so, you are already saying you're happy hacking these files by hand, so you're probably not the sort to be using the tools that care about the distinctions anyway. Regardless, the change isn't going to have an effect on day-to-day system operation.
Best Answer
The key in the user database,
/etc/passwd
or something else, is the login name: that’s all that you provide to identify yourself when you log in. From that key, a program can retrieve all the other information stored in the user database; this happens with no regard for any other user in the user database, even other users with the same user id. (Typically, this is done withgetpwnam
orgetpwnam_r
, either directly or via PAM.)Thus the login name leads to the stored password, the user id, the (primary) group id, the GECOS information, the home directory and shell. This means that two users can share the same user id, yet have different home directories and shells! (This was commonly used in the past to provide a fall-back, statically-linked shell for root; you’d have the usual
root
user with id 0 and shell/bin/bash
or whatever, and another user, saysashroot
, with id 0 and a different shell.)Hence the answer to
is that it depends only on the user name.
The key in the group database is also the group name. From that key, a program can retrieve all the other information stored in the group database; again this happens with no regard for any other group in the group database. (When determining a user’s secondary groups, the process is more complex than reading the user database: there is no function to list groups to which a given user belongs, so this is typically done in a loop involving
getgrent
andendgrent
.)Thus the group name leads to the group password, group id, and the list of group members, which is a list of user names. To build a user’s set of secondary groups, all the groups are enumerated, and the user’s login name is matched against the group’s members. So not only can two different users with the same user id have different primary groups, they can belong to a different set of secondary groups!
Hence the answer to
is that a user’s groups only depend on the user name, and different user names can share a user id yet have different primary and secondary groups.