IRC channel logs
2026-08-06.log
back to list of logs
<damo22>youpi: the only fails on CI now match with what is reported <gnu_srs>solid_black: Please don't blame me. Other people were also included in creating that patch. And: Why did you not propose a patch yourself as a solution? <solid_black>erm, I didn't mean for that to read as blaming, sorry if it came out that way <solid_black>I proposed some ideas there, but got no real feedback <solid_black>I think I like the last idea -- adding new auth server RPCs and sticking with SCM_CREDS as an API -- most, but I do wonder what others think <damo22>linux has strange hanging issues on cifs filesystems <damo22>i wonder if we can do a better one <damo22>where is the source for /hurd/smbfs <youpi>the source of a debian package is documented in /usr/share/doc/thepackage/copyright <damo22>what is fcntl_lock? and fcntl_lock64? <damo22>-#if !(defined(HAVE_FCNTL_LOCK) || defined(HAVE_STRUCT_FLOCK64)) <damo22>- printf("ERROR: No locking available. Running Samba would be unsafe\n"); <damo22>is this something that stops us from upstreaming libsmbclient changes? <youpi>see the lock part of man fcntl <damo22>thats weird i cant clone from salsa error: RPC failed; curl 92 HTTP/2 stream 5 was not closed cleanly: CANCEL (err 8) <rsmarples>solid_black: if anything, please implement getpeereid(3) as that is common amongst all the BSD's <rsmarples>OpenBSD for example don't have any method of receving creds via the control socket. <damo22>youpi: are samba not taking any patches for series 3.x anymore ? <damo22>i noticed it seems to be a very old version that we are using for libsmbclient 3.0.5, but they are up to 4.x now <damo22>the latest source tree has a source3 and source4 split <damo22>how do i find out if i should try to upstream to master or an old branch? <solid_black>getpeerid would be possible, the issue with it (same one as mentioned in the mail): transfering numeric UID/GID over RPC is sad <solid_black>a better way is having a peer actively authenticate to you, through the auth server/protocol <solid_black>this can then be exposed as some Unix-level API that outputs numeric UID/GID, but it needs the peer to be actively engaged <solid_black>but getpeereid doesn't require the peer to be engaged, you could just call it at any time, while the peer is doing something else and not paying any attention to the socket <solid_black>SCM_CREDS OTOH is something that the peer actively sends to you, so that part is covered <damo22>i used the patch in the incubator and modified it for samba and the debian package seems to be compiling on master <rsmarples>solid_black: it's also only supported on FreeBSD and has a fixed supplimental group limit <sam_>damo22: pretty sure 3.x is extremely dead <rsmarples>solid_black: and why should the peer be engaged in anyway or form? it's not necessary <sam_>the last relevant branch upstream is v3-6-stable i think which is from 2015 <solid_black>because that's how the auth dance works, one actor (client) actively authenticates to the other (server) <youpi>rsmarples: because creating a socket does not curently require identifying oneself to the tcp/ip or unix stack <youpi>so the tcp/ip or unix stack does really know not who created the socket <solid_black>because you have to already have an authenticated port to pflocal to create a socket <youpi>there's the fs auth before the socket creation indeed <solid_black>my only concerns about using this are: it only stores a single uid/gid, whereas we should support multiple gids at least; but more importantly, adding an RPC to pflocal to fetch these would transfer numeric UID/GID over RPC <youpi>I mean, that's what such cred retrieval provide: the identity of who created the socket <solid_black>a bit more details toward the end of that email ^ above <rsmarples>youpi: and this is why LOCAL_CREDS option exists. client connects to it and knows to authenticate silently. this is server driven