How do groups work on Linux?

I really wasn't. I was just making a point that it's not just Linux-specific like you claimed. In fact if you re-read the thread you'd realise that nobody argued this behaviour was universal. Given the breadth of POSIX-like systems out there, I doubt anyone would dare make such a bold statement. So you're arguing against point that was never raised.

> And by the way, filesystems are typically implemented in kernel, so saying that it's not kernel that handles them is somewhat misguided.

Well yes file systems generally are, except when they are not. For example ntfs-3g (which is also compiled against FUSE). Plus the file system code is modular - not in the monolithic vs microkernel sense but rather in terms of the body of code is a self-contained chunk that can be optionally compiled in or not. This also means that some file systems are written with some degree of portability in mind (easier said than done I know!!!)

What the argument is about is whether the permission logic described (specifically the setgid bit on folders) is handled by the file system code or externally to the file system code in other parts of the kernel (thus the behavior is defined by the OS rather than the file system).

You're making the case that the behavior is independent to the file system implementation (thus the logic is handled outside the file system code) because it is OS-specific. I'm stating that when I've been writing file systems I've had to handle that logic inside the file system code itself thus the logic is not OS-specific but rather file system-specific.

Now there will be standard way of implementing the logic because people will have certain expectations about how the file system should behave. Much like most $SHELL's broadly follow a common POSIX standard. So you would get the illusion of the discussed behavior being OS-specific even though the actual business logic is implemented at a different stage in the stack (ie the file system code). There might also be instances where one OS might patch the file system code to change its behavior to match the expectations of that OS - but I'm just speculating here. All I know is that I've had to write the logic myself - the kernel did not handle that for me.

I'm obviously not boasting to be a low level kernel hacker so I'd happily bow to a more reasoned argument but the examples you've given have just been guesswork about kernel operations based on some flawed experimentation with user space tools (I say 'flawed' because you didn't even bother to set the setgid bit in your original example when you suggested FreeBSD didn't support said behavior).

> Hint: what's the ownership of a file created on FAT mounted under Linux? It should suggest you what part of the kernel needs to handle the permissions.

That doesn't prove either of our points. Nor anything aside that Linux can mount FAT file systems.

    shabble@host:~$ cp /bin/chmod /tmp/chmoo
    shabble@host:~$ chmod 600 /tmp/chmoo
    shabble@host:~$ ll /tmp/ch*
    -rw------- 1 shabble shabble 59K Nov 21 17:15 /tmp/chmoo
    shabble@host:~$ /tmp/chmoo
    -bash: /tmp/chmoo: Permission denied
    shabble@host:~$ /lib64/ld-linux-x86-64.so.2 /tmp/chmoo
    /tmp/chmoo: missing operand
    Try '/tmp/chmoo --help' for more information.

> I really wasn't. I was just making a point that it's not just Linux-specific like you claimed.

I never claimed it's Linux only, only that there are other systems with different semantics.

>> And by the way, filesystems are typically implemented in kernel, so saying that it's not kernel that handles them is somewhat misguided.

> Well yes file systems generally are, except when they are not. For example ntfs-3g [...]

...except that FUSE is in-kernel mechanism to delegate VFS callbacks to userspace program. It's hard to argue in such a case that the work is not the kernel's responsibility.

> What the argument is about is whether the permission logic described (specifically the setgid bit on folders) is handled by the file system code or externally to the file system code in other parts of the kernel

Oh. This explains quite a bit, because I thought the argument was about whether the OS' usual semantics (group being inherited from directory or from EGID) are like that or not, not where in kernel this behaviour is coded.

> You're making the case that the behavior is independent to the file system implementation [...]

No, I'm making the case that Linux usually works one way, and BSD usually works the other way. I never claimed that anything was coded in any specific kernel subsystem, so don't add the statement yourself.