Scenario 1:
I have 2 users, each has a different primary group.
For user1, the primary group is group1 with GID 501.
For user2, the primary group is group2 with GID 502.
I edited /etc/passwd so that user1 now has GID 600.
However, I forgot to create a new group with GID 600 (and I did not edit /etc/group either).
What's surprising me is that even though I never created a group with GID 600 (and thus there's no such group in /etc/group)- everything works as if such a group exists:
Examples:
1) After user1 creates a new file- test.txt, User2 can't r/w that file.
2) When running ls -l I can see that test.txt belongs to GID 600.
What am I missing? Why does it work even though there's inconsistency between /etc/passwd and /etc/group?
Scenario 2:
Say I have a group with GID 1000.
When running useradd -c "name" test2 -g 1000, and then groups test2, I can see that test2's primary group is 1000.
However, in /etc/group all I see is test_group:x:1000:, meaning test2 isn't a member of test_group.
Moreover, after running useradd -c "name" test3, I do have test3:x:8093: in /etc/group.
Can you explain why it's happening?
Thanks.
Non programming question, expect downvotes... you should ask on superuser or unix.se
That said, there is no mapping of UID numbers to GID numbers that require them to have the same values. Think about what happens when you add a few users, then create a group or two for them to share, then add a few more users. The "next available" GID/UID pair don't match in value, but that doesn't matter.
When you are looking at a user's primary group, they aren't listed in the groups file as being a member because their primary group info is in the passwd file.
Remember to find files/directories that have no owning user or group if you manually change a UID number or GID number, and fix as appropriate.
Also, when it comes to UID numbers and GID numbers there is 0 (root) and everything else - no special meaning to them. By consensus, "system user" type accounts are low, and most distributions start creating "normal" users with a UID/GID of 1000
Related
i am using "getent" command to fetch user information in my linux file system.
I have a user with the username "10798" and another user with the username "user" and user ID "10798",i am using getent command to fetch the user info of user with the name "10798"
but the command is not giving any output
I think the command "getent" will only look for the user id number if you give all numeric value as input to the command
here is the scenario
# cat /etc/passwd
10798:x:10799:10799::/home/10798:/bin/bash
user:x:10798:10798::/home/user:/bin/bash
# getent passwd 10798
user:x:10798:10798::/home/user:/bin/bash
how to get the user with the username 10798 using the getent command
passwd When no key is provided, use setpwent(3), getpwent(3),
and endpwent(3) to enumerate the passwd database. When
one or more key arguments are provided, pass each
numeric key to getpwuid(3) and each nonnumeric key to
getpwnam(3) and display the result.
I got this from the linux man page is there a way to redirect numeric keys to getpwnam
ls already performs that lookup. You can perform a user information lookup from the command line with getent passwd.
If ls shows a user ID instead of a user name, it's because there's no user by that name. Filesystems store user IDs, not user names. If you mount a filesystem from another system, or if a file belongs to a now-deleted user, or if you passed a numerical user ID to chown, you can have a file that belongs to a user ID that doesn't have a name.
On a shared host, you may have access to some files that are shared between several virtual machines, each with their user database. This is a bit weird (why share files but not the users that own them?), but it's technically possible.
I saw:
chmod o-rwx somefile
This will remove read/write/execute permissions from other users (doesn't include users within your group).
How can I remove write permission only for current user?
Permissions in linux are given for user (who is the owner of the file), group (which is the group of the owner of file by default (though youcan change using chgrp command)) and others. Every file has 3 permissions for each of these categories (Read, Write and Execute), which are represented by setting or unsetting of corresponding bits. So, permissions range from 0 to 7, where 0 is no permission, 1 is x, 2 is w, 3 is wx, 4 is r, 5 is rx, 6 is rw and 7 is rwx.
So, use chmod abc filename where a/b/c are numbers in range 0-7 for user, group and others respectively.
I have some questions about getent group.
Where does getent group A get the information on group A?
Does it only get it from /etc/group?
Is it possible that I can find a user (belonging to group A) by getent group A while I can not find the user from group A in /etc/group? If yes, how could this happen?
The third one is actually the problem I met.
Example:
1st. [root#*** test]# getent group A | grep A
2nd. [root#*** test]# cat $INSTALLROOT/etc/group | grep A
I can find a user a from the first command while I cannot find the user a from the second command.
Where does "getent group A" get the information on group A?
It is configured in /etc/nsswitch.conf. man getent tells this.
Does it only get from /etc/group?
It depends on your config files. On my machine it does not get this information only from /etc/group since it is configured in this way:
group: files ldap
is it possible that i can find a user (belong group A) by "getent group A" while can NOT find the user from group A in /etc/group?
Yes it is possible if there are at least two sources of data for groups.
By the way, take a look at how getent group work - run it under strace.
strace -s 256 -o getent.strace.txt -v getent group
And see what system calls it does. In my case it first reade from /etc/group and loads an ldap module and starts reading from socket
I know there's 0,1,5,6 and 7 for each category of user
e.g. 755, 644, 600 etc
how many combinations can we have?
also, there's this u+755... what is this about really?
There are 4 user-manipulable permissions locations (special permissions [setuid, setgid, sticky], user owner, group owner, other), and each can have one of 8 values.
8 ** 4 = 4096
The 3 numbers denote owner/group/world
Each of them has read/write/execute bits. You are setting these when it comes to the 3 numbers.
So, 000 becomes
owner group world
rwx rwx rwx
000 000 000
777 (which allows everyone to read, write and execute the file) becomes
owner group world
rwx rwx rwx
111 111 111
644 allows owner to read/write. Group and world to only read.
owner group world
rwx rwx rwx
110 100 100
And so on..
In total, there are 8 bits, which can be turned on/off, giving you 8^3. In addition, there are the special modes Sticky bit, SUID and SGID, and their various combinations, further giving you 8 possibilities.
the unix privileges on directories is categorised by [User][Group][Other] each of these have the options of [Read][Write][Execute]
so the form is [User]{RWX},[Group]{RWX},[Other]{RWX}
so the permissions are [U]RWX [G]RWX [O]RWX so if you are familiar with the binary representation of decimal numbers you can understand that
755 would be decoded to [U]111 [G]101 [O]101 so this means [U]RWX [G]R-X [O]R-X
600 would be decoded to [U]110 [G]000 [O]000 so this means [U]RW- [G]--- [O]---
644 would be decoded to [U]110 [G]100 [O]100 so this means [U]RW- [G]R-- [O]R--
and about the available combinations are 2^9= 512 available permissions
where 2 is the number of available choices (0,1) that could be placed in one of the 9 available places
[U]123 [G]456 [O]789 in the general form.
you can check this link for further details and tutorial.
Every file and directory has their certial set of permissions on User (who owns the files), Group (Group is to which that user belongs and all the users belongs to this group will fall in this category) and Others ( rest of the users and group present inside the system).
Now each of these categories (User/Group/Others) can have combination of Read, Write or Execute permissions.
Read - 4
Write -2
Execute - 1
So if a file has [read,write, execute] permissions for User and [read,execute] permission for Group and Others both then it is denoted as
chmod 755 filename
also, chmod u+rwx, g+rx, o+rx filename
Now if you just want to give USER (the first category) permissions on the file as [read,write] then it will be like :-
chmod u+rw filename.
I don't think the command (chmod u+755 filename) you have written is correct.
I have problem with OpenLdap and permission to file.
First - I set this in my slapd.conf:
overlay dynlist
dynlist-attrset labeledURIObject labeledURI
Second - I make cn=test,ou=Projects,dc=example,dc=com with:
dn: cn=test,ou=Projects,dc=example,dc=com
gidNumber: 6789
objectClass: posixGroup
objectClass: top
objectClass: labeledURIObject
labeledURI: ldap:///cn=testgroup,ou=Groups,dc=example,dc=com?memberUid?sub?
(objectClass=posixGroup)
memberUid: user1 (dynamic)
memberUid: user2 (dynamic)
in cn=testgroup,ou=Groups,dc=example,dc=com i have memberuid: user1 and memberUid: user2
Third - when i made getent group test I have:
test:*:6789:user1,user2
But when I try id user1 i didn't see this group :(
And next I set chmod 770 dir and chown root.test dir and try access to this dir.
But of course it is not possible because the user is not in this group (that said "id").
Does anyone know the solution?
Third - when i made getent group test I have:
test:*:6789:user1,user2
But when i try id user1 i didn't see this group :(
Unfortunately dynamic lists (dynlists) are ONE WAY groups (not TWO way). This means that reverse lookups won't work, which causes the very issue you are now facing. There is no way to make reverse posix group lookups work with dynlist.
HOWEVER, there is another module available somewhere on OpenLDAP's site I believe. It is called autogroup. This is a static-group maintainer module. This method of grouping does not involved dynamic data, rather it is REAL data that is automagically managed by the autogroup module. However, it is configured similar to a dynlist group as it uses the labeledURI attribute to allow a "stored procedure" so to speak.
I too was disappointed when I realized the shortcomings of dynlist, and I should point out that autogroup is still somewhat experimental. Test thoroughly and report any bugs to OpenLDAP.
I hope this helps...
Max
Groups are constructed here in this way without memberUid, but member:
dn: cn=mygroup,ou=groups,o=company
objectClass: posixGroup
objectClass: top
objectClass: groupOfNames
cn: mygroup
member: uid=user1,ou=users,o=company
displayName: mygroup
gidNumber: 1234
The schema type is also to be set to RFC2307bis (ldap_schema = rfc2307bis in sssd.conf).
For the 3rd issue, the problem is that id will use a ldap request with (member=uid=login,... ) while getent group will search for the group ( cn=groupname ). So the 2nd one trigger the overlay , while the first don't ( see the man page ). I also faced the issue, and found some links about it :
http://www.openldap.org/lists/openldap-software/200708/msg00250.html and http://www.openldap.org/lists/openldap-devel/200708/msg00127.html.
So far, I didn't found any good solution, maybe changing nss_ldap would work ( if you use it, which you didn't explained )