IRC channel logs
2025-01-07.log
back to list of logs
<Gooberpatrol66>what interests me is spritely + guix people want to turn guix into an "object capability OS" <Gooberpatrol66>this could give us a framework for programs to use mach capabilities directly instead of using hurd's unix-like compatibility layer <damo22>i have no idea what that all means <damo22>it sounds like they want to make permissions more like selinux <damo22>youpi: i noticed that on GNU/Linux you cant put a group inside another group... can hurd support such a thing? <damo22>i think groups are very useful when nestable <damo22>since you can grant permissions to a group, it would be useful to be able to inherit groups of permissions just by adding a group to another group <damo22>for example, if you wanted a subset of users to be in a group that was allowed to access both pci and usb, you could create 3 groups, pci, usb and bus, and put pci and usb into the bus group and then add the bus group to the users, but /servers/bus/pci would be assigned the pci group and /servers/bus/usb would be assigned usb group so the permissions are still separately managed but grouped into "bus" <damo22>then you would not need to assign the pci or usb group to the users, only the bus group <damo22>when the user tries to access a file that is in the pci or usb group, it checks the group hierarchy of bus to decide if the user has access to the file as a group permission, naturally the user would be permitted to access the file under the group permissions set by the file, but under the top level group <youpi>concerning groups, the Hurd doesn't currently go beyond posix <damo22>working in my current job, ive found the lack of posix group nesting is a huge limitation <damo22>managing fine grained permissions is difficult <damo22>the change i am suggesting could be backward compatible, since it would still allow putting everything into separate groups, but with an extra feature that you could put a group inside another group... <Gooberpatrol66>could there be like a group translator that exposes groups as a fs tree? <damo22>it would need to be tied in fairly tightly with the file permission model <damo22>because it would need to be a slightly different parsing of /etc/group probably <ZhaoM>hi, any recommended document for 'part store'? <damo22>ZhaoM: i think its a layer that parses a MBR partition table and mounts the corresponding partition number via the underlying block device <damo22>but it does not require a second translator node on wd0s2 <damo22>at boot, we dont have a root filesystem for the separate partition nodes <ZhaoM>do you mean we don't need to know the file system type to mount? <youpi>it's just that it's the ext2fs process that does the partition table parsing, rather than the kernel or another translator <youpi>in both cases ext2fs ends up reading the same piece of the disk <youpi>it's just the exact piece of process that parses the partition table that changes <youpi>that being said, ext2fs could be fine with using a storeio translator sitting on /dev/wd0s2 <youpi>because there is a file_get_storage_info RPC that allows it to know the piece of disk to use, and then open wd0 directly <youpi>instead of reads/writes having to needlessly go through the storeio translator <youpi>I don't know if ext2fs already knows how to do it, possibly libstore already does know <azert>I like the idea of damo22 a lot, the one about nested groups. <sneek>Welcome back azert, you have 1 message! <sneek>azert, youpi says: richard rewrote pieces, yes <damo22>i do know if it were supported on GNU/Linux, it would simplify a lot of group mappings <azert>but you want to avoid having to parse the group file twice, better require sorting of that file <azert>I’ve checked OCapN, seems like the typical heavy security infrastructure that is in the fancy today <azert>Few use seLinux, most don’t care <damo22>everything security related in hurd is basically a posix file permission right? <azert>I think that the auth server allows you to get groups and user rights on the flight <ZhaoM>ok so an ext2fs process is for parsing the partition used for root fs <ZhaoM>I can see the process using `ps -aux | grep ext2fs` <ZhaoM>I started getting confused with the storeio translator <ZhaoM>`showtrans /dev/hd0s2` gives me `/hurd/storeio hd0s2` <ZhaoM>what is the use of the storeio translator in `/hurd/storeio hd0s2`? <ZhaoM>Hope the question is not too stupid :) <gnu_srs1>(00:49:29) gnu_srs1: (17:28:01) gnu_srs1: (22:23:16) gnu_srs1: (12:56:13) gnu_srs1: Hello. sysvinit does not install reboot and halt executables since they should be supplied by hurd. However hurd only installs reboot-hurd and halt-hurd. <gnu_srs1>(00:49:29) gnu_srs1: (17:28:01) gnu_srs1: (22:23:16) gnu_srs1: (12:56:13) gnu_srs1: This causes /etc/init.d/checkroot.sh to fail, not finding the reboot executable. Similar problems with halt, e.g. the script /etc/init.d/halt. <gnu_srs1>(00:49:29) gnu_srs1: (17:30:04) gnu_srs1: The hurd.postinst has the following line: update-alternatives --quiet \ ...--slave /sbin/reboot reboot /sbin/reboot-hurd \... <gnu_srs1>(00:49:29) gnu_srs1: (19:19:25) gnu_srs1: I don't really understand the slave option of update-alternatives. Does it apply only to the execution of the script /etc/hurd/runsystem?? <damo22>ZhaoM: an ext2fs process is mainly for reading and writing to an ext2 filesystem, but it also has ability to parse a partition table i think <ZhaoM>damo22: ah i see. `ext2fs --readonly --multiboot-command-line=root=part:2:device:hd0 --exec-server-task=1 -T typed part:2:device:hd0` is the command executed in bootstrap <ZhaoM>`part:2:device:hd0` can be an evidence showing that ext2fs can understand partition table <Pellescours>damo22: no need of nested group, just add all needed groups to the user <youpi>sneek: later tell ZhaoM yes, ext2fs can understand partition tables, thanks to using libstore which uses libparted behind. But then that's the issue: libparted is gpl3 while ext2fs is gpl2-only, so we need to separate them in two translators, a storeio and ext2fs <youpi>gnu_srs1: “sysvinit does not install reboot and halt executables since they should be supplied by hurd.” why "should be supplied by hurd" ?? reboot & halt are really supposed to be provided by sysvinit-core <youpi>it's initscripts.postinst which sets up the alternative <gnu_srs1>I don't really understand the slave option. Why not just --install the links? <youpi>because it has to deal with various packages providing the commands, and the user preference <youpi>as well as making sure that they are coherent <gnu_srs1>This makes sense: update-alternatives --display editor <gnu_srs1>For sysvinit no executables halt-sysv, etc are created <youpi>then investigation is needed <gnu_srs1>The file debian/not-installed lists: sbin/poweroff; sbin/reboot. <gnu_srs1>Seems like there were some problems sysv-files install runsystem slaves at /usr/sbin while hurd installs at /sbin. <gnu_srs1>Which runsystem to use? /etc/hurd/runsystem.sysv: "exec /etc/hurd/runsystem.gnu init=/sbin/init" <gnu_srs1>But then /sbin/halt, etc points to /usr/sbin/sysv-halt not /sbin/hurd-halt?? <youpi>that changed in 3.08-7 apparently indeed <youpi>I was actually thinking about moving hurd's bin/* to usr/bin/ to keep coherent with the rest of the debian ecosystem