I'm having two directories: "public" and "private".
I have three users: "chris", "john", "dan". I have two groups: "pub", "priv" and "god".
The group "god" should have full access to "public" and "private".
The group "pub" should be the only group to have permissions over "public"
The group "priv" should be the only group to have permissions over "private".
As root:
useradd chris
useradd john
useradd dan
usermod -g god chris
usermod -g pub john
usermod -g priv dan
chgrp god public private
chgrp pub public
chgrp priv private
su chris
As "chris":
cd public/
touch test = permission denied
The same for the other users ... under "dan" I have no permissions over the "private" directory, althou "dan" is a member of the "priv" group.
Do you have any idea?
Well, I know this is relatively old, but twalberg is correct: there's actually a relatively easy way to accomplish this with POSIX ACL's. They've existed since the late 90's/early 2000's so I don't know why more people don't use them.
How to do it: Do as you've already done, then simply execute this command:
# setfacl -m g:god:rwx public private
and in one command you get what you're wanting. You'll spend forever trying to figure out how to do it using ONLY traditional unix permissions.
Mikic's advice may still be good (depending on what you're trying to accomplish), and it might be more straight forward to reference as few groups as possible in your permissions (or maybe you want it to be apparent that "chris" isn't a regular user, but an administrative one, again it depends on what you want to construct).
I offered something closer to what you're trying to accomplish, because there may be situations where you're trying to give a secondary user/group access to a directory but you don't want to choose between "chris" not getting access to these two directories and "chris" getting access to all those other files and directories "pub" and "priv" might have access to. With ACL's you don't have to make those choices, which is why they were added and are now a core part of most Unix (and BSD and Linux) platforms.
You said that the group "pub" should be the only group to have permissions over "public". But right before that you said that "god" should also have access. So "pub" can't be the only one that has access. Ditto for "priv".
You also say:
I have two groups: "pub", "priv" and "god".
Well, that's three groups. (Reminds me of that famous quote: "There's three kinds of people in this world; those who can count and those who can't." :-P)
Your base concept seems wrong. The way this works is rather simple. Create two groups, "pub" and "priv". Place all users who need access to the directories accordingly. Users who need access to both directories should belong to both groups.
In this case, "chris" should be put in both the "pub" as well as the "priv" group. "john" should be put in the "pub" group. "dan" should be put in the "priv" group.
What you were trying to do is having the directories be owned by two groups. That's not possible. It's users who can be part of multiple groups, not files or directories. You simply got it backwards :-)
There are two problematic things in your approach. The first one is:
chgrp god public private
chgrp pub public
With second command, you discarded the effect of the first one. Directory public now belongs to pub group, not to god anymore.
The second thing is that you probably didn't give write permissions on directory public to group that owns it (the fact that the user executing the command touch belongs to directory's group doesn't matter).
Try this:
chmod 770 public
and do similar with other directories. However, what you're initially trying to achieve is impossible because the directory can belong to one group only. Nikos elaborated it well in his answer - place user in more groups.
You will need to use a file system that supports ACLs. As mentioned in other answers, the pub and priv group ownership is possible with the basic Linux permissions, but to grant access to the god group, since files/directories can only have a single group tag, will require an ACL. Most of the current file systems should support this functionality - see the manual pages for getfacl and setfacl.
Related
This thread points to a webpage that no longer exists: How to change a perforce user to superuser
How do I change the Perforce Protections Table?
Run p4 protect, and add a line like:
super user joe-bob * //...
Each protection entry has five parts:
the access level (super)
whether the entry is for a user or a group
the name of the user/group (joe-bob)
the client IP range this entry applies to (usually * for "everywhere")
the depot path this entry applies to (there's no point in restricting super access to a narrow path since they have permission to edit the protection table themselves anyway, so for super entries this is almost always //...).
Mirror Question: https://unix.stackexchange.com/questions/217300/where-how-is-user-group-information-stored-in-ubuntu. (I'll remove one of them after I got the answer)
Two places possible: /etc/group and /etc/passwd.
If I use command: adduser [username] [groupname], then the user would be added to the group, and the file /etc/group would then be updated.
However, the file /etc/passwd is not updated. if I check which group I belongs to, via groups command, I can only see groups stated in passwd file.. therefore, the user is not added to the group base on this result.
I'm confused.
What's the meaning of storying group info into /etc/passwd, and /etc/group respectively?
Why adduser only update the group file?
How to add group to the passwd file via command?
Why does groups return group info from passwd file, but not group file?
Thanks.
In these traditional text files (there are other ways, e.g. LDAP), your primary group goes to /etc/passwd (it's e.g. used for permissions of files you create), all additional groups go to /etc/group.
see 1.
That's impossible, but you can change a primary group with usermod -g
That's a misinterpretation, groups shows all groups. But a new group is only picked up when you start a new session (new login). You can use the newgrp command, that starts a session with the given group name as your primary group (you must be member of this group) -- as a side effect, it will consult the user database and update your groups list.
I want to expose a REST service and use the permission context to call different methods (simple user vs admin user).
What I did (simple example):
config.add_route('rest', '/url')
....
#view_config(route_name="rest", renderer="json", request_method='GET', permission='user')
def firstMethod(request):
...
#view_config(route_name="rest", renderer="json", request_method='GET', permission='admin')
def secondMethod(request):
...
But I have the following error when I start pyramid :
"ConfigurationConflictError: Conflicting configuration actions"
for firstMethod and secondMethod
Any ideas to solve my problem ? (I know that I can use principals but I need to use permission and not principal...)
Your permissions right are labeled like principals, not permissions, so you might want to think about how you're actually using permissions. Principals are more like characteristics (groups), whereas permissions are like verbs (what can a user do).
As Martijn said, the way the ACL model works it's very difficult in a general sense to reason about whether one permission is mutually exclusive with another for arbitrary permissions. For example, are 'admin' users not 'user' users?? I guess that's up to you.
Pyramid provides a tiny way to cheat via the effective_principals predicate, if these are actually principals that you want to differentiate. Again you have to make sure they are mutually exclusive or you won't know which view will be invoked.
#view_config(route_name='foo', effective_principals=['admin'])
If admins also have the 'user' principal, then you'd leave 'user' out of the next view_config, as such:
#view_config(route_name='foo')
Now it's unambiguous.
The way to make this unambiguous in other cases is with your own view predicates.
#view_config(route_name='foo', is_admin=True)
#view_config(route_name='foo', effective_principals=[Authenticated])
config.add_view_predicate('is_admin', AdminPredicate)
I am using getent group command to get the groups along with there usernames in linux. But it is not showing any usernames for some groups which i know exist.
i need this info is there any other way around?
Picking up 1st two results :--
root:x:0:
bin:x:1:bin,daemon
as you can see there are no users for group root and 2 users in bin group. I know that the root group contains a user root but its now showing it here.
What you are missing is that each user has a primary group, which is stored in /etc/passwd (usually in field 4), and may have one or more supplementary groups. Only the supplementary group associations are in /etc/group, and as a result, are the only ones that getent group will show. In order to get the entire list of groups for a particular user, you can use id -a <user>, but you'll have to iterate that over the list of users to get your full information dump...
Can you please run:
getent group|diff /etc/group -
and show us the difference in its output,
Since I have run this and I see no difference their both exactly the same
getent will only return the master group name and not the sub groups a user belongs to:
getent group adm
adm:x:4:me,logcheck
To get any instances of adm within getent try:
getent group|grep adm
I've been struggling with this off and on for months, and it may be non-trivial to answer.
What is the easiest way to limit public access to an item and its subitems to members of a single role? (Editors still need to be able to edit the item.)
e.g. There's a role, extranet/clubmember, and items,
- Clubhouse
| - Items
| - Inside
| - Clubhouse
And I want extranet/clubmember members to be able to read the items and subitems, sitecore/* members (Or, say, sitecore/editor) to have edit access, and everyone else (in default and extranet domains) to be denied.
Second, does this solution still work with a custom role and membership providers for extranet? Why or why not, or what methods do I need to implement? I recall from earlier experiments that my custom role provider seems to affect Inheritance permissions in particular.
Have you tried the following:
uncheck Inherit for Everyone (the global one) to Clubhouse root
explicitly allow Read for extranet\clubmember to Clubhouse root
explicitly allow Read/Write for sitecore\Everyone to Clubhouse root
Explicit assignments always win. So, that scheme should have the effect you expect.