1

I got an exercise to create a directory called Projekte and I'm supposed to give the groups Auftrag and Support the permissions r and w but the others only r

I just realised that this is impossible. What can I do?

Thanks for any help

  • Would creating a new group to which you add all affected users be an option? This would force you to have to manage individuals in multiple groups though, rather than groups of individuals... – Kusalananda Jun 4 '18 at 11:40
  • I don't know whether our teacher meant this but that is a great idea. I could possibly create secondary groups to merge the users of both groups into one helper group. The problem would be that I have more exercise like that and this would be very unclear – Grevak Jun 4 '18 at 11:45
  • That would be the "classic" way of doing it, but someone who knows about ACLs (or some other relevant mechanic) may have a better answer. – Kusalananda Jun 4 '18 at 11:48
  • If you got this as an exercise, then it's very likely not impossible. Don't assume something is impossible because you don't know how :-) – Patrick Jun 4 '18 at 12:33
0

You would not be able to do this by creating a new group, as you need some users to have read and some to have read/write. That is unless you need the users from Auftrag and Support to have read/write and everyone else to have read permissions, in which case you could create a group which contains all the users from Auftrag and Support, and set group write and world read.

Alternatively, and assuming your filessytem supports them, you could use extended ACLs: https://wiki.archlinux.org/index.php/Access_Control_Lists

For example:

# setfacl -m "g:Auftrag:rw" /file/path

# setfacl -m "g:Support:rw" /file/path
  • 1
    I'm not sure what schily is talking about, these commands certainly do work in a quick test I just did, using btrfs – rusty shackleford Jun 4 '18 at 12:14
  • 2
    @schily An answer that answers the question is of great use. I'm also going to repeat the ask of "what are you talking about?". Please back up your claims if you're going to make them. – Patrick Jun 4 '18 at 12:29
  • 1
    @rustyshackleford There are a few things about this answer that should be adjusted/noted. The question is asking about a directory, thus it needs the execute bit as well. Also with filesystem ACLs, even if the group has all perms stripped prior to the setfacl, the setfacl will add some back. Thus it's important to make sure the group of the file is either one of the groups that should have access, or is a group nobody is in (or something like root). – Patrick Jun 4 '18 at 12:41
  • 1
    As much as I enjoy a good debate. He (schily) has no intention of backing up his claim, or providing any sort of proof. So lets just let him spew whatever he wants to spew. – Patrick Jun 4 '18 at 12:43
  • 2
    @schily What I think people are hoping is that you could at least back up your claim. Do you have a link to support your claims about 1993 and 1997? Are you in the context of Linux, or another OS? All I'm seeing out there are modern references to this method. Not only that, I'm seeing it as the only apparent / most visible method. Does it not work in all major Linux distributions, is that a concern? – groovenectar Nov 22 '18 at 4:21
2

I have to assume that the goal includes the execute bit as well in order to change into the directory.

Become the root user.

sudo -i

Create the directory. (The root user is the owner and group owner.)

mkdir Projekte

Define the permissions. Let's make it accessible only to root to highlight the affect of the ACLs.

chmod 0700

Now augment standard permissions with ACLs.

setfacl -d -m g:Auftrag:7 Projekte
setfacl -m g:Auftrag:7 Projekte

setfacl -d -m g:Support:7 Projekte
setfacl -m g:Support:7 Projekte

setfacl -d -m o::5 Projeckte
setfacl -m o::5 Projeckte

Above, the -m switch is the mask, and the -d switch makes the mask the default mask for all new filesystem objects in the directory. Octal values need not be used. The same can be written as follows.

setfacl -d -m g:Auftrag:rwx Projekte
setfacl -m g:Auftrag:rwx Projekte

setfacl -d -m g:Support:rwx Projekte
setfacl -m g:Support:rwx Projekte

setfacl -d -m o::r-x Projeckte
setfacl -m o::r-x Projeckte

The user, group, and other masks work the same way: g:groupname:--- or in combination: u:username:---,g:groupname:---,o::---, where o means others. Not specifying a username or group name applies the mask to current user/group ownership.

Notice how both a mask and a default mask were applied. The mask (without -d) applies to the directory itself. The mask (with -d) applies to all new filesystem objects in the directory. It's easy to forget this.

  • See other comment: a proposal to standardize this flavor of ACLs has been withdrawn in 1997. – schily Jun 4 '18 at 12:08
  • Nevertheless it works all day every for decades until today, – Christopher Oct 2 '18 at 12:12
  • So you either work on a platform with a filesystem that has not been made up to date since 20 years, or you work on a platform where the creators do not care about recent standards. All modern filesystems that have been written after y2000 support the NFSv4/NTFS ACL concept (see Mac OS, AIX, Solaris/ZFS, FreeBSD). Old filesystems however may still use this old ACL concept, but Solaris/SAMFS and FreeBSD did upgrade even some old filesystems to support the current ACL standard. – schily Oct 2 '18 at 13:12
  • The tag is linux. – Christopher Oct 2 '18 at 13:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.