6 ms·
> Except it does work FreeBSD: Congratulations, you have an incomplete example. And what exactly did you want to prove? That an OS-specific behaviour can be e
by dozzie 9y ago
> Except it does work FreeBSD:
Congratulations, you have an incomplete example.
And what exactly did you want to prove? That an OS-specific behaviour can be
exhibited by more than one OS?
- laumars 9y agoYou said, and I quote, "it's Linux-specific" and I was demonstrating that it's not Linux-specific. I also question your point that it's "OS-specific" because I'm pretty sure I had to handle the permission logic myself in the hobby file systems I've written (albeit they were compiled against FUSE rather than kernel objects). However I don't have any examples to hand which I can provide to that end. Hopefully a more experienced file system developer can jump in here as to whether this behavior is controlled by the OS or by the file system. However the fact that you can alter it's behavior via mount options would also suggest I'm right.
- dozzie 9y ago> You said, and I quote, "it's Linux-specific" and I was demonstrating that it's not Linux-specific. You were attempting at demonstrating that the OS specific behaviour can also be exhibited elsewhere (also, you failed at that attempt; you haven't shown what group your shell belongs to). If you were to demonstrate that it's universal (as opposed to be OS specific), you would need to invoke some standard that describes the behaviour, which you didn't. > I'm pretty sure I had to handle the permission logic myself in the hobby file systems I've written 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. And by the way, filesystems are typically implemented in kernel, so saying that it's not kernel that handles them is somewhat misguided. It's just that Linux implementations of filesystems usually set the group of the file to the EGID of the process that created the file.
- laumars 9y ago> If you were to demonstrate that it's universal 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.
- zamber 9y agoCongratulations, you're passive-aggressive here without any reason to be. Explains the downvote flood pretty well.