21–30 of 68 posts
Earlier quoted context omitted.
While it’s nice to have it as default behavior when it makes sense, it’s also nice to have setgid as an option rather than the rule.
Nice or not, you can't talk about directory's SGID behaviour as it was unversal truth, because it's Linux-specific, and even then it's something that can be changed.
Earlier quoted context omitted.
Except it does work FreeBSD: [lau@primus ~/test]$ mkdir setgid nosetgid [root@primus /home/lau/test]# chmod g+s setgid [root@primus /home/lau/test]# chgrp lau setgid [lau@primus ~/test]$ ls -l total 1 drwxr-xr-x 2 lau users 4 21 Nov 14:52 nosetgid drwxr-sr-x 2 lau lau 4 21 Nov 14:51 setgid [lau@primus ~/test]$ touch {nosetgid,setgid}/test [lau@primus ~/test]$ ls -l * nosetgid: total 1 -rw-r--r-- 1 lau users 0 21 Nov…
> 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?
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.
The book she mentions, "The Linux Programming Interface," sounds pretty useful, but it's seven years old at this point. Does anyone know how much has changed or if there's a new version coming any time soon? Seems like it's worth $70 but the age has me concerned. I'm sure the basics, like the things this article is about, haven't changed, but I bet all the stuff around cgroups would be useful for how setgid works wit…
One of the most useful group-related tricks (introduced in BSD Unix, I believe) is the setgid bit on a directory. If this is set, new files and subdirectories created within the directory will have the same group as the directory, rather than the group of the process that created them.
I use this as a basic indicator of someone's Unix competency. Not as a straight binary thing, but if I'm talking to someone (interviewing or maybe debugging something) I've found that if you know about setgid/setuid you have probably been interested enough to know what you are doing.
Ohh, so THAT's why I have to log out and back in to have my group changes take effect. That, along with having to start a new shell to pick up new env vars from ~/.profile, are my two biggest annoyances with the Linux process model. Reminds me a bit of the Windows 98 days when you had to restart to change your IP address. I really wish someone would sit down and figure out how to propagate group and environment chang…
Take a look at the command “newgrp”
addgroup && newgrp
Ohh, so THAT's why I have to log out and back in to have my group changes take effect. That, along with having to start a new shell to pick up new env vars from ~/.profile, are my two biggest annoyances with the Linux process model. Reminds me a bit of the Windows 98 days when you had to restart to change your IP address. I really wish someone would sit down and figure out how to propagate group and environment chang…
The book she mentions, "The Linux Programming Interface," sounds pretty useful, but it's seven years old at this point. Does anyone know how much has changed or if there's a new version coming any time soon? Seems like it's worth $70 but the age has me concerned. I'm sure the basics, like the things this article is about, haven't changed, but I bet all the stuff around cgroups would be useful for how setgid works wit…
Useful is an understatement of The Linux Programming Interface (TLPI), yes seven years old but the only major thing that has probably changed is the number of syscalls has risen, other than that, still solid for understanding the OS primitives and interfaces that the Kernel uses to interact with user land. On the BSD side "The Design and Implementation of the FreeBSD Operating System (2nd Edition)" is also a great bo…
This doesn't make sense.
Earlier quoted context omitted.
> 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?
You 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 ex…
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.