[17:35] `grub-efi-amd64` is apparently getting a security fix but apt seems to be phasing its distribution as on some of my machines it is listed as being "kept back" [17:35] is this normal for security fixes to have "phasing" applied? [17:36] https://termbin.com/du4o => what I ran [17:41] hmm, `apt policy` (https://termbin.com/x2s3) doesn't even show this package as being available through http://security.ubuntu.com/ubuntu/ [18:05] yo #security, do you recall why in ubuntu we don't share [homes] by default in samba? https://pastebin.ubuntu.com/p/FmkZXNVCqx/ [18:05] maybe because home was 0755 until recently? [18:05] but still, over the network, you would only be able to see the contents of home through samba if you authenticated as the user [18:06] that commit was from 2013, for trusty [18:07] maybe to avoid clear-text traffic of things like ~/.gnupg, ~/.ssh and such? [18:08] back then it was clear text, I'm almost sure [18:08] ahasenack: I can't remember exactly, but I still don't think it's a good idea to enable that by default...especially since it would allow access to home directories with simple passwords? [18:08] ahasenack: nowadays those files are denied access by smbd's Apparmor policy [18:09] * sdeziel wonders if smbd's AA policy defaults to enable [18:09] sdeziel: you mean the samba apaprmor? Sorry, not there by default [18:09] ah, sorry then [18:09] hint: I'll try to get it in good shape for lunar lobster [18:10] mdeslaur: first you would have to create the samba user matching your linux user (smbpasswd -a ) [18:10] and that password can be anything, yes [18:10] hrm [18:10] I thought we were using something that did that automatically [18:10] so uncommenting [homes] won't export it by default [18:11] didn't we have pam integration or something? [18:11] I mean, it will be visible, but there will be no set of credentials to access it [18:11] there are pam account restrictions that samba should follow, yes [18:12] and "unix password sync", and some horrible expect-like "chat" setting, if you use the network RPC calls to change a user's password [18:12] but the tdb file with the samba user passwords is born empty [18:13] I can try some of those remotely, see if they do anything nowadays, with a default config [18:13] ahasenack: I was even more wrong, the smbd profile doesn't even include the `` I think it did :/ [18:13] I'll take note of that [18:13] oh, there is a lot of stuff in there [18:15] I'd have to trace back to when we did the change and try and find the uds discussion about it [18:15] the changelog has no bug number, too bad [18:16] it was done by zulcss [18:16] (Chuck SHort) [18:16] actually, you need the -strict version (``) to block `~/.ssh/` and `/.gnupg/` [18:16] in 2:4.0.10+dfsg-4ubuntu1 [18:17] here: https://git.launchpad.net/ubuntu/+source/samba/commit/?h=import/2%254.0.10%2bdfsg-4ubuntu1&id=16a3ec29185c83d7a4d9a5c59cd680f9a406bc8a [18:17] -ubottu:#ubuntu-security- Commit 16a3ec2 in ubuntu/+source/samba "2:4.0.10+dfsg-4ubuntu1 (patches unapplied) import/2%4.0.10+dfsg-4ubuntu1" [18:19] I have a feeling the change is older than that, he just dropped the history there [18:19] * mdeslaur looks [18:21] samba (3.0.22-1ubuntu3) dapper; urgency=low [18:21] * Config file changes only in this upload; no destabilising code changes. [18:21] * Comment out the default [homes] shares and add more verbose comments to [18:21] explain what they do and how they work (closes: launchpad.net/27608) [18:21] https://bugs.launchpad.net/ubuntu/+source/samba/+bug/27608 [18:21] -ubottu:#ubuntu-security- Launchpad bug 27608 in samba (Ubuntu) "Entire home dir is shared within another in samba!" [Medium, Fix Released] [18:22] ahasenack: I think I remember now....gnome directory sharing used samba, so as soon as you right clicked on a directory and shared it, samba would share your home directory without you knowing [18:23] yeah, that's why we disabled that [18:27] ah, good find about the older change [18:27] that gnome share thing still exists, but it requires you to run "sudo smbpasswd -a " nowadays, or last I checked [18:27] I think back then in 3.0.x days, samba was using plain text passwords still perhaps? [18:28] remember one had to change a registry setting in windows to get it to use plain text passwords and then work with samba? [18:28] this would be one way to get it to work without the smbpasswd command, samba could then just check /etc/shadow as any other app (get the clear text password from the user, hash it, compare) [18:31] hrm, I think it would ask you to set a password [18:31] I'd have to try it [18:31] one sec [18:32] I do know upstream gnome switched to clear text webdav at some point, but we kept samba integration [18:34] ugh, no attachments to that bug, just links to external sites, links that are dead now of course [18:35] ah [18:35] the guy shared a directory within his home, and gave the *share* the name of his user [18:35] which of course triggers [homes] [18:36] wouldn't sharing any other directory do the same thing, as soon as you set the password? [18:36] no, the username is special [18:36] if you access //server/, it will clone the [homes] share and create a share called [your-linux-user] [18:37] but he had a share [your-linux-user] already created, for another directory [18:37] via gnome [18:37] I don't know if this is undefined behavior (two shares with the same name pointing at different paths) [18:37] but it's something I can try [18:37] well, if [homes] is configured, isn't your home directory shared as soon as you create a password? [18:38] about the cloning of [homes], I mean samba will create [your-linux-user] with a path of ~your-linux-user (i.e., your-linux-user's $HOME) [18:41] how the heck is gnome creating the share...I can see it but I have no idea where it's telling samba to add it [18:41] if [homes] is configured, any access to //server/valid-linux-user will create [valid-linux-user] with the settings from [homes]. If [homes] requires a password, then you will need a password. The extra nice setting to have is "valid users = %S", so the only valid user for that share will be the actual home owner [18:41] gnome is using a dynamic share mechanism, just a sec, I even fixed a bug in that for jammy or kinetic [18:42] "usershare" is its name [18:42] there is a sambashare unix group [18:43] search for "USERSHARES" in man smb.conf [18:46] ah, it's in /var/lib/samba/usershares huh [18:51] it's nautilus-share: https://bugs.launchpad.net/ubuntu/+source/nautilus-share/+bug/1967245 [18:51] -ubottu:#ubuntu-security- Launchpad bug 1967245 in nautilus-share (Ubuntu) "'net usershare' returned error 255 on jammy-desktop-amd64" [High, Fix Released] [18:51] ah yes, that's it === ahasenack_ is now known as ahasenack [18:57] ahasenack: perhaps we can talk about this next week at the sprint [18:58] I won't be there I'm afraid (phisically), but I'll attend remotely, time shifting [18:58] ah, I see [18:58] I'm revisiting this because it's one delta we have with debian [18:59] I'd like amurray to chime in on this...I still think it's odd to share everyone's directories by default, it's kind of unexpected [19:00] it's a valid point [19:20] well, the good news is that nautilus-share (well, the "net usershare" command from samba, which creates these shares) does not allow you to create a share that matches a local user [19:20] """'net usershare' returned error 255: net usershare add: share name debian is already a valid system user name""" [19:21] I have a local debian user, and opted to share my ~/Videos directory, but gave the share the name "debian" [19:21] and I don't even have [homes] enabled [19:21] so maybe the concerns of that original bug are gone, but it's still a valid point of discussion, if we should share [homes] by default or not [19:22] for now, I'll keep it as is, of course (not sharing) [19:22] it's a small delta with debian anyway [19:28] this usershare thing is wonky === fauxpride- is now known as fauxpride === martums6 is now known as martums