6 ms·

[dozzie@zorn /srv]$ ls -ld foo drwxrwxrwx 2 root wheel uarch 2 Nov 21 12:57 foo/ [dozzie@zorn /srv]$ touch foo/nabla [dozzie@zorn /srv]$ ls -l foo/nabl

by dozzie 9y ago

[dozzie@zorn /srv]$ ls -ld foo drwxrwxrwx 2 root wheel uarch 2 Nov 21 12:57 foo/ [dozzie@zorn /srv]$ touch foo/nabla [dozzie@zorn /srv]$ ls -l foo/nabla -rw-r--r-- 1 dozzie wheel uarch 0 Nov 21 12:58 foo/nabla [dozzie@zorn /srv]$ id uid=1001(dozzie) gid=1001(dozzie) groups=1001(dozzie) [dozzie@zorn /srv]$ uname -s -r FreeBSD 11.0-RELEASE-p1 This is called "BSD semantics". You can get the same behaviour with appropriate mount option for Ext2/3/4 and XFS.

jwilk 9y ago
What filesystem was that? And why is this behavior filesystem-specific?
- dozzie 9y ago
  Not what filesystem, it's what OS. FreeBSD. And ZFS, but UFS works the same.
  - laumars 9y ago
    I could be wrong but I thought the file system's "drivers" did the handling of file system permissions rather than the OS / kernel? Or at least this was my experience when playing around with FUSE on hobby projects.
  - jwilk 9y ago
    So why did you mentation "Ext2/3/4 and XFS" if filesystem doesn't matter?
    - dozzie 9y ago
      I don't see what you don't understand. I demonstrated that on FreeBSD created file inherits the group of its parent directory even without SGID, i.e. that FreeBSD exhibits BSD semantics. I also added that if you can have BSD semantics on Ext2/3/4 and XFS if you mount them under Linux with appropriate options.
      - deleted 9y ago
        [deleted]
      - jwilk 9y ago
        No, you didn't say anything about Linux.
      - drvdevd 9y ago
        You’re getting downvoted a bunch here, but I believe your basic point is valid. To take it back to the GP: SGID bit and other such OS and/or filesystem specific semantics are not the best measurement of someone’s overall UNIX understanding. Now, IMO asking someone if they understand what the difference is between chmod <octal notation> VS chmod <friendly notation> is and why it exists is a bit more telling, because this touches down on what interface most unix filesystems try to present and also how they’re implemented to a degree. The specifics on any given system are just a manpage away but the general understanding only really comes from having absorbed some actual unix interactions. And certainly knowing more than just Linux should get one bonus points...
delinka 9y ago
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.
- dozzie 9y ago
  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.
  - laumars 9y ago
    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 14:52 test setgid: total 1 -rw-r--r-- 1 lau lau 0 21 Nov 14:51 test Looking at your example, I'd guess you didn't set the setgid bit as your `ls` doesn't show the group column to be `S` (instead stating `X` which is the default a directory would be set as). OS build and file system: [lau@primus ~/test]$ uname -a FreeBSD primus 10.3-RELEASE-p11 FreeBSD 10.3-RELEASE-p11 #0: Mon Oct 24 18:49:24 UTC 2016 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 [lau@primus ~/test]$ mount | grep " / " zroot2 on / (zfs, local, nfsv4acls)
    - 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 ago
        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 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.

by dozzie 9y ago

jwilk 9y ago

What filesystem was that? And why is this behavior filesystem-specific?

dozzie 9y ago
Not what filesystem, it's what OS. FreeBSD. And ZFS, but UFS works the same.
- laumars 9y ago
  I could be wrong but I thought the file system's "drivers" did the handling of file system permissions rather than the OS / kernel? Or at least this was my experience when playing around with FUSE on hobby projects.
- jwilk 9y ago
  So why did you mentation "Ext2/3/4 and XFS" if filesystem doesn't matter?
  - dozzie 9y ago
    I don't see what you don't understand. I demonstrated that on FreeBSD created file inherits the group of its parent directory even without SGID, i.e. that FreeBSD exhibits BSD semantics. I also added that if you can have BSD semantics on Ext2/3/4 and XFS if you mount them under Linux with appropriate options.
    - deleted 9y ago
      [deleted]
    - jwilk 9y ago
      No, you didn't say anything about Linux.
    - drvdevd 9y ago
      You’re getting downvoted a bunch here, but I believe your basic point is valid. To take it back to the GP: SGID bit and other such OS and/or filesystem specific semantics are not the best measurement of someone’s overall UNIX understanding. Now, IMO asking someone if they understand what the difference is between chmod <octal notation> VS chmod <friendly notation> is and why it exists is a bit more telling, because this touches down on what interface most unix filesystems try to present and also how they’re implemented to a degree. The specifics on any given system are just a manpage away but the general understanding only really comes from having absorbed some actual unix interactions. And certainly knowing more than just Linux should get one bonus points...

delinka 9y ago

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.

dozzie 9y ago
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.
- laumars 9y ago
  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 14:52 test setgid: total 1 -rw-r--r-- 1 lau lau 0 21 Nov 14:51 test Looking at your example, I'd guess you didn't set the setgid bit as your `ls` doesn't show the group column to be `S` (instead stating `X` which is the default a directory would be set as). OS build and file system: [lau@primus ~/test]$ uname -a FreeBSD primus 10.3-RELEASE-p11 FreeBSD 10.3-RELEASE-p11 #0: Mon Oct 24 18:49:24 UTC 2016 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 [lau@primus ~/test]$ mount | grep " / " zroot2 on / (zfs, local, nfsv4acls)
  - 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 ago
      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 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.