similar to: cifs.upcall not respecting krb5ccname env var?

Small respin of the patches that I posted a few days ago. The main difference is the reordering of the series to make it do the group and grouplist manipulation first, and then the patch that makes it grab the KRB5CCNAME from the initiating process. I think the code is sound, my main question is whether we really need the command-line switch for this. Should this just be the default mode of

Chad reported that he was seeing a regression in cifs-utils-6.6. Prior to that, cifs.upcall was able to find credcaches in non-default FILE: locations, but with the rework of that code, that ability was lost. Unfortunately, the krb5 library design doesn't really take into account the fact that we might need to find a credcache in a process that isn't descended from the session. When the

On Mon, 2017-02-13 at 05:02 -0500, Simo Sorce wrote: > On Sat, 2017-02-11 at 10:16 -0500, Jeff Layton wrote: > > On Sat, 2017-02-11 at 08:41 -0500, Jeff Layton wrote: > > > Chad reported that he was seeing a regression in cifs-utils-6.6. > > > Prior > > > to that, cifs.upcall was able to find credcaches in non-default > > > FILE: > > >

Apologies for v3 series, I had some extra patches in there. This is the one that should have been sent. Relabeled as v4 for clarity. Third respin of this series. Reordered for better safety for bisecting. The environment scraping is now on by default, but can be disabled with "-E" in environments where it's not needed. Also, I've added a patch to make cifs.upcall drop

Third respin of this series. Reordered for better safety for bisecting. The environment scraping is now on by default, but can be disabled with "-E" in environments where it's not needed. Also, I've added a patch to make cifs.upcall drop capabilities before doing most of its work. This may help reduce the attack surface of the program. Jeff Layton (4): cifs.upcall: convert

> > I should have mentioned this earlier, but the users does not exist > > in /etc/passwd, instead they are in LDAP and when they log in to the > > computer they get some Kerberos tickets for the domain and the file > > system. When printing on 14.04 they get another Kerberos ticket for > > the printing system according to "klist" after they have done

On 02/10/2020 13:01, Jason Keltz via samba wrote: > On 10/2/2020 5:25 AM, Rowland penny via samba wrote: > >> On 01/10/2020 21:46, Rowland penny via samba wrote: >>> On 01/10/2020 21:23, Jason Keltz via samba wrote: >>>> >>>> >>>> Okay - I guess the failure of kdc: lines in smb.conf is a bug. >>>> >>>> Let's wait

Hello, Trying to compile Samba 3.2.15 on a RHEL AS 4u2 (i686) and I'm getting the following result from 'sh makerpms.sh': > Provides: samba-doc = 3.2.15-1 > Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(VersionedDependencies) <= 3.0.3-1 > > > RPM build errors: > File not found:

On Sat, 5 Aug 2017 19:06:49 +0200 Van Svensson via samba <samba at lists.samba.org> wrote: > > > I should have mentioned this earlier, but the users does not exist > > > in /etc/passwd, instead they are in LDAP and when they log in to > > > the computer they get some Kerberos tickets for the domain and > > > the file system. When printing on 14.04 they

Currently, we leave the group ID alone, but now that we're looking at KRB5CCNAME, we need to be a little more careful with credentials. After we get the uid, do a getpwuid and grab the default gid for the user. Then use setgid to set it before calling setuid. Signed-off-by: Jeff Layton <jlayton at samba.org> --- cifs.upcall.c | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed,

On Fri, 2017-02-10 at 11:15 -0600, Chad William Seys wrote: > Hi Jeff, > > > So we have a default credcache for the user for whom we are operating > > as, but we can't get the default principal name from it. My guess is > > that it's not finding the > > This mount is run by root UID=0 and seems to be find that credential > cache without problem (earlier

Maybe its.. authconfig --enablewinbindkrb5 --update Requirements to achieve this: - A valid /etc/krb5.conf - A valid system keytab /etc/krb5.keytab - A valid /etc/samba/smb.conf -> will be modified by authconfig ( found on internet worked in centos7 ) But better read.. https://sssd.io/docs/users/pam_krb5_migration.html Greetz, Louis > -----Oorspronkelijk bericht----- >

Rowland Penny wrote: > On Sat, 5 Aug 2017 15:29:54 +0200 > Van Svensson via samba <samba at lists.samba.org> wrote: > > > Rowland Penny wrote: > > > > > On Sat, 5 Aug 2017 14:44:34 +0200 > > > Van Svensson via samba <samba at lists.samba.org> wrote: > > > > > > > Rowland Penny wrote: > > > > > > >

On 01/10/2020 21:46, Rowland penny via samba wrote: > On 01/10/2020 21:23, Jason Keltz via samba wrote: >> >> >> Okay - I guess the failure of kdc: lines in smb.conf is a bug. >> >> Let's wait and see what happens with your ticket after 10 hours. >> Maybe there's a bug there as well. > It will be in the middle of the night here, so I will report

Is anyone on the list using kerberized-nfs on any kind of scale? I've been fighting with this for years. In general, when we have issues with this system, they are random and/or not repeatable. I've had very little luck with community support. I hope I don't offend by saying that! Rather, my belief is that these problems are very niche/esoteric, and so beyond the scope of typical

I believe there is a bug in how AIX handles the KRB5CCNAME environment variable. The symptom occurs when a root user restarts sshd while they have KRB5CCNAME set; all of the resulting client connections will inherit the same KRB5CCNAME variable. This can occur if the admin uses 'ksu' or some other kerberized method of obtaining root privileges. Investigating this problem, I stumbled

http://bugzilla.mindrot.org/show_bug.cgi?id=757 Summary: KRB5CCNAME inherited from root's environment under AIX Product: Portable OpenSSH Version: -current Platform: PPC OS/Version: AIX Status: NEW Severity: minor Priority: P2 Component: sshd AssignedTo: openssh-bugs at mindrot.org

Hello all. I'm encountering an issue where smbclient seemingly ignores the kerberos ccache as configured in krb5.conf when using "krb5-user" as the kerberos package and will instead always default to using "FILE:/tmp/krb5cc_uid". I tested each valid default ccache name type but smbclient completely ignores whatever is set as the "default_ccache_name" in the conf

http://bugzilla.mindrot.org/show_bug.cgi?id=751 Summary: KRB5CCNAME set incorrectly in GSSAPI code Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Kerberos support AssignedTo: openssh-bugs at mindrot.org

http://bugzilla.mindrot.org/show_bug.cgi?id=372 Summary: [authkrb5] : KRB5CCNAME set to pointer Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: basalt