01:58:56 <_xor> Hmm, what would happen if one were to set /dev/null as the home dir in /etc/passwd? (instead of /nonexistent)
01:59:40 <RhodiumToad> probbly nothing good
02:00:28 <RhodiumToad> some users use /var/empty, which exists but is immutably empty
02:00:40 <_xor> Is /nonexistent a historical artifact or something? I mean if there's nothing special about it and it's just assumed to not exist, I wonder if there's a potential attack vector there.
02:01:01 <RhodiumToad> oh, creating it would cause all kinds of fun
02:01:34 <_xor> Like if /nonexistent is set as some users home dir, but an attacker manages to somehow create one through some exploit in some service...well, then I do know there are a bunch of accounts with that set as the default, so that would potentially open up those accounts to use as part of a further exploit?
02:01:54 <_xor> Ah yeah ok makes snese.
02:03:02 <_xor> Oh dear lord
02:03:11 * _xor is grepped /etc/passwd for nonexistent
02:03:16 <RhodiumToad> I think /var/empty (or if it really needs to not exist, /var/empty/nonexistent ) makes rather more sense
02:04:06 <RhodiumToad> though even with /var/empty, you're trusting that the schg flag is properly set, and root can still turn that off unless you're running with an elevated securelevel
02:04:24 <_xor> Hmm, well at least it's a child of the door directory, so I guess an exec running under one of those accounts would need to have suid set to be able to create one (easily anyway).
02:04:33 <_xor> *root
02:05:50 <_xor> Just theoretically, could it be set to a specific dev device instead that basically just logs reads/writes to it and returns whatever the ENOEXIST error is for it?
02:06:22 <RhodiumToad> you could probably rig devfs to do something of the sort
05:08:24 <bjornn> i noticed that on freebsd, when i switch to root with doas it still keeps the users home directory as $HOME
05:32:24 <parv> Does "doas" have "-" argument|option to do the "normal" login as "su -" does?
06:43:00 <tercaL> "Installed packages to be UPGRADED: clamav: 1.1.0_1,1 -> 1.1.1,1" <- Yay!
06:43:11 <tercaL> Cool news of the morning.
09:21:05 <carlavilla> someone have experience with framework laptop and FreeBSD?
09:21:17 <carlavilla> they just opened the purchases to Spain :)
09:54:59 <vkarlsen> carlavilla: Have you read this? https://xyinn.org/md/freebsd/framework_laptop
09:55:00 <VimDiesel> Title: FreeBSD on the Framework Laptop | @fearedbliss
09:58:29 <vkarlsen> Also, of course: https://wiki.freebsd.org/Laptops/Framework_Laptop
09:58:31 <VimDiesel> Title: Laptops/Framework_Laptop - FreeBSD Wiki
10:04:50 <carlavilla> This machine is now on Linux. No further FreeBSD updates will be provided on this page. <<< :'(
10:04:58 <carlavilla> vkarlsen: thanks, I'm gonna take a look
13:26:06 <anandprabhu> Hi everyone, I setup a new FreeBSD 12 server using AWS Lightsail and while configuring the ssmtp by mistake changed the permissions of the $USER folder. How can I know the default permissions of the $USER folder and change it?
13:34:00 <anandprabhu> Fixed it now. Thanks!
13:35:21 <TommyC> anandprabhu: umask?
13:36:27 <anandprabhu> TommyC - nope updated the user folder permissions using chmod
15:09:40 <debdrup> Well, the skeleton file for sh in /usr/share/skel/dot.shrc includes a umask while it's commented out for csh (and therefore also tcsh), so it depends on what shell you set.
15:10:19 <debdrup> umask(2) defines what that means.
19:13:50 <blastwave> I see opensbi 1.3.1 at freshports maintained by mhorne but I do not see a clear u-boot package that makes sense. For qemu do I still need u-boot for RISC-V ?
20:03:56 <concrete_houses> I have 3 usb spinning disk attached how do I get iostat to show the work they are doing?
20:04:26 <concrete_houses> it seems to not show da1 da2
20:05:18 <RhodiumToad> gstat -p  is better
20:05:42 <vkarlsen> Have you tried specifying them as parameters to iostat?
20:08:13 <concrete_houses> gstat -p is nicer
20:08:16 <concrete_houses> let me try
20:15:33 <concrete_houses>  iostat  -d da0 -d da1 -d da2 4 works
22:20:37 <checkpoint> hello
22:22:22 * checkpoint 's bit amazed by more than 600 users sitting on this channel all silent at once
22:24:56 <accelerat0r> more bugs searching and less chachara
22:33:43 <CyberCr33p> Hello. Does FreeBSD needs a kernel patch for AMD Inception like linux? Or the only way is to wait for the microcode update from AMD?
23:39:46 <kenrap> CyberCr33p: I'm assuming you reported this just now? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273238
23:39:49 <VimDiesel> Title: 273238 – cpu-microcode-amd: AMD "Inception" security vulnerability fix for Zen 3 and Zen 4 processors
23:40:37 <CyberCr33p> kenrap yes I did. But this is only for zen 3 & 4. I have some zen 2 servers too.
23:41:22 <CyberCr33p> kenrap I guess AMD will release microcode for zen 2 soon
23:45:49 <CyberCr33p> kenrap I found this part in an article: "AMD's Zen 3 and Zen 4 CPUs are affected by what is known as the 'Inception' vulnerability. Like many recent attacks, this one is a side channel attack that can lead to the exposure of otherwise secure data. AMD says its Zen 1 and Zen 2 generations are unaffected."
23:46:03 <CyberCr33p> kenrap so it looks like no update is needed for zen 2
23:54:46 <dvl> checkpoint: You're new to IRC? I think not.  But silence is better than spouting off topic.
23:58:12 <kenrap> CyberCr33p: Hopefully AMD will release those microcode updates. Right now there is a lot of hustle from the FreeBSD developers in getting the stable/14 branch ready and they've been working extremely hard to refactor and cleanup the src.