[prev in list] [next in list] [prev in thread] [next in thread] 

List:       samba-technical
Subject:    Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy
From:       ronnie sahlberg via samba-technical <samba-technical () lists ! samba ! org>
Date:       2021-04-13 23:53:42
Message-ID: CAN05THRsOHnBZRLFhmTKv5V-6sTun7oQeX7tMUjMPnTpQ9DN=Q () mail ! gmail ! com
[Download RAW message or body]

Pavel,

What is the status of this patch and getting it into cifs-utils?
The are reported to work in tests by some folks and they do provide
desired new functionality.


regards
ronnie sahlberg

On Sat, Mar 6, 2021 at 8:20 AM Simo Sorce <simo@redhat.com> wrote:
> 
> On Fri, 2021-03-05 at 16:29 -0500, Jacob Shivers wrote:
> > if nfs-client is to be used as well as cifs-client, then wouldn't a
> > different socket be required? Testing with cifs-client using the same
> > socket returns an error from gssproxy:
> > 
> > "cifs sets allow_any_uid with the same socket, selinux_context, and
> > program as nfs-client!".
> 
> The point is that you do not need a separate service definition if you
> are configuring them the same way :-)
> If you want different configurations but same access pattern, then yeah
> different sockets help. So it is just a metter of figuring out what
> works best.
> 
> > Leveraging the built-in functionality of gssproxy is preferable as
> > that addresses use cases where the process was started manually and
> > not via systemd. Would it be reasonable to ever add gid filtering to
> > gssproxy? I ask as that would allow for a group of batch
> > processes/applications to have access where say applications could be
> > added to a fixed group name/gid but, different uids may be deployed
> > over time as different applications are used.
> 
> Yes I think adding gid filtering is a feature I find useful, feel free
> to open an issue describing the semantics you think would make more
> sense for your use case. Implementation is not hard, but nailing the
> semantics is important.
> 
> Simo.
> 
> > On Tue, Feb 23, 2021 at 2:54 PM Simo Sorce <simo@redhat.com> wrote:
> > > Nice work!
> > > 
> > > Notice that GSS-Proxy can already perform access control, so you do not
> > > have to create additional sockets or the systemd script, but you can
> > > simply create service files in gssproxy that filter based on uid or
> > > even SELinux context if you like.
> > > 
> > > There are additional filters based on the calling program too, but
> > > those are not to be used to enforce security measures as argv[0] is
> > > under the control of the user.
> > > 
> > > HTH,
> > > Simo.
> > > 
> > > On Tue, 2021-02-23 at 12:42 -0500, Jacob Shivers wrote:
> > > > I have tested the patches for cifs.upcall and can say that with some
> > > > additional modifications to gssproxy the end setup brings a degree of
> > > > feature parity to SMB clients that had been previously exclusive to
> > > > NFS clients.
> > > > Deployment does require some additional configuration, including the
> > > > creation of a drop-in file for gssproxy under /etc/gssproxy and for
> > > > the gssproxy service managed by systemd
> > > > 
> > > > 
> > > > ### KDC configuration
> > > > 
> > > > *** delegation ***
> > > > 
> > > > Constrained Delegation (CD) for the SMB host to the Kerberized SMB server
> > > > Resource Based Constrained Delegation (RBCD) on the Kerberized SMB
> > > > server to determine which SMB clients can delegate
> > > > 
> > > > 
> > > > ### SMB client configuration
> > > > 
> > > > *** sssd ***
> > > > 
> > > > Configuration file modification.
> > > > 
> > > > Disable using fully qualified domain names as impersonation does not
> > > > correctly handle fully qualified names at time of ticket acquisition.
> > > > 
> > > > use_fully_qualified_names = False
> > > > 
> > > > *** gssproxy ***
> > > > 
> > > > Drop file creation
> > > > 
> > > > Add a drop file for gssproxy to create the necessary socket and
> > > > corresponding settings.
> > > > 
> > > > # cat /etc/gssproxy/99-cifs-client.conf with contents
> > > > [service/cifs]
> > > > mechs = krb5
> > > > socket = /var/lib/gssproxy/cifs.sock
> > > > cred_store = keytab:/etc/krb5.keytab
> > > > cred_usage = initiate
> > > > euid = 0
> > > > impersonate = yes
> > > > allow_any_uid = yes
> > > > 
> > > > Service drop-in file.
> > > > 
> > > > Create a drop-in file to limit socket access for an unattended user, if \
> > > > desired. 
> > > > # cat /etc/systemd/system/gssproxy.service.d/90-cifs.conf
> > > > [Service]
> > > > # Limit cifs.sock socket file accessiblility to just the unattended user.
> > > > ExecStartPost=/bin/bash -c 'chmod 660 /var/lib/gssproxy/cifs.sock &&
> > > > setfacl -m u:chang:rw /var/lib/gssproxy/cifs.sock'
> > > > 
> > > > 
> > > > *** cifs.upcall ***
> > > > 
> > > > cifs.spnego.conf modification
> > > > 
> > > > Allow for gssprxy to be used and specify socket file
> > > > 
> > > > # cat /etc/request-key.d/cifs.spnego.conf
> > > > create  cifs.spnego    * *  /usr/bin/env GSS_USE_PROXY=yes
> > > > GSSPROXY_SOCKET=/var/lib/gssproxy/cifs.sock /usr/sbin/cifs.upcall %k
> > > > 
> > > > include the '-t' flag to allow for accessing a Kerberized DFS
> > > > namespace using a domain based mount, i.e //example.net/dfs/share
> > > > 
> > > > create  cifs.spnego    * *  /usr/bin/env GSS_USE_PROXY=yes
> > > > GSSPROXY_SOCKET=/var/lib/gssproxy/cifs.sock /usr/sbin/cifs.upcall -t
> > > > %k
> > > > 
> > > > 
> > > > The above does allow for unattended users to access a Kerberized SMB
> > > > share while limiting access to only a specific user:
> > > > 
> > > > # mount //win2k16-dfs1.example.net/greendale/ /mnt -o
> > > > sec=krb5,username='TEST-BOX$@EXAMPLE.NET',multiuser
> > > > 
> > > > # su - jeff
> > > > Last login: Fri Feb  5 12:14:42 EST 2021 on pts/0
> > > > [jeff@test-box ~]$ ll /mnt
> > > > ls: cannot access '/mnt': Permission denied
> > > > [jeff@test-box ~]$ logout
> > > > 
> > > > # su - chang
> > > > Last login: Fri Feb  5 12:14:46 EST 2021 on pts/0
> > > > [chang@test-box ~]$ klist
> > > > klist: No credentials cache found (filename: /tmp/krb5cc_602001123)
> > > > [chang@test-box ~]$ ls -l /mnt
> > > > total 143
> > > > 
> > > > drwxr-xr-x. 2 chang domain users      0 Oct  4  2018  DfsrPrivate
> > > > -rwxr-xr-x. 1 chang domain users      0 Sep 22 10:07  test_file
> > > > -rwxr-xr-x. 1 chang domain users      0 Dec 14 15:22  whoami
> > > > drwxr-xr-x. 2 chang domain users      0 Dec  7 12:54  winhome
> > > > 
> > > > [chang@test-box ~]$ klist
> > > > klist: No credentials cache found (filename: /tmp/krb5cc_602001123)
> > > > 
> > > > 
> > > > Feb 23 12:22:44.857956 test-box.example.net su[1672]: (to jeff) root on pts/1
> > > > Feb 23 12:22:44.866263 test-box.example.net su[1672]:
> > > > pam_systemd(su-l:session): Cannot create session: Already running in a
> > > > session or user slice
> > > > Feb 23 12:22:44.867158 test-box.example.net su[1672]:
> > > > pam_unix(su-l:session): session opened for user jeff by root(uid=0)
> > > > Feb 23 12:22:46.253310 test-box.example.net cifs.upcall[1700]: key
> > > > description: \
> > > > cifs.spnego;0;0;39010000;ver=0x2;host=win2k16-dfs1.example.net;ip4=192.168.124.132;sec=krb5;uid=0x23e1cedc;creduid=0x23e1cedc;pid=0x6a3
> > > >  Feb 23 12:22:46.253335 test-box.example.net cifs.upcall[1700]: ver=2
> > > > Feb 23 12:22:46.253338 test-box.example.net cifs.upcall[1700]:
> > > > host=win2k16-dfs1.example.net
> > > > Feb 23 12:22:46.253342 test-box.example.net cifs.upcall[1700]:
> > > > ip=192.168.124.132
> > > > Feb 23 12:22:46.253344 test-box.example.net cifs.upcall[1700]: sec=1
> > > > Feb 23 12:22:46.253348 test-box.example.net cifs.upcall[1700]: uid=602001116
> > > > Feb 23 12:22:46.253352 test-box.example.net cifs.upcall[1700]: \
> > > > creduid=602001116 Feb 23 12:22:46.253365 test-box.example.net \
> > > > cifs.upcall[1700]: pid=1699 Feb 23 12:22:46.253978 test-box.example.net \
> > > >                 cifs.upcall[1700]:
> > > > get_cachename_from_process_env: pathname=/proc/1699/environ
> > > > Feb 23 12:22:46.254995 test-box.example.net cifs.upcall[1700]:
> > > > get_existing_cc: default ccache is FILE:/tmp/krb5cc_602001116
> > > > Feb 23 12:22:46.255015 test-box.example.net cifs.upcall[1700]:
> > > > get_tgt_time: unable to get principal
> > > > Feb 23 12:22:46.255021 test-box.example.net cifs.upcall[1700]:
> > > > handle_krb5_mech: getting service ticket for win2k16-dfs1.example.net
> > > > Feb 23 12:22:46.255024 test-box.example.net cifs.upcall[1700]:
> > > > handle_krb5_mech: using GSS-API
> > > > Feb 23 12:22:46.259295 test-box.example.net cifs.upcall[1700]: GSS-API
> > > > error init_sec_context: Unspecified GSS failure.  Minor code may
> > > > provide more information
> > > > Feb 23 12:22:46.259306 test-box.example.net cifs.upcall[1700]: GSS-API
> > > > error init_sec_context: No Kerberos credentials available (default
> > > > cache: FILE:/tmp/krb5cc_602001116)
> > > > Feb 23 12:22:46.259311 test-box.example.net cifs.upcall[1700]:
> > > > handle_krb5_mech: failed to obtain service ticket via GSS (851968)
> > > > Feb 23 12:22:46.259314 test-box.example.net cifs.upcall[1700]: Unable
> > > > to obtain service ticket
> > > > Feb 23 12:22:46.259323 test-box.example.net cifs.upcall[1700]: Exit
> > > > status 851968
> > > > Feb 23 12:22:46.262827 test-box.example.net kernel: CIFS VFS:
> > > > \\win2k16-dfs1.example.net Send error in SessSetup = -126
> > > > Feb 23 12:22:47.398266 test-box.example.net su[1672]:
> > > > pam_unix(su-l:session): session closed for user jeff
> > > > Feb 23 12:22:49.159640 test-box.example.net su[1702]: (to chang) root on \
> > > > pts/1 Feb 23 12:22:49.173264 test-box.example.net su[1702]:
> > > > pam_systemd(su-l:session): Cannot create session: Already running in a
> > > > session or user slice
> > > > Feb 23 12:22:49.173967 test-box.example.net su[1702]:
> > > > pam_unix(su-l:session): session opened for user chang by root(uid=0)
> > > > Feb 23 12:22:51.878743 test-box.example.net cifs.upcall[1729]: key
> > > > description: \
> > > > cifs.spnego;0;0;39010000;ver=0x2;host=win2k16-dfs1.example.net;ip4=192.168.124.132;sec=krb5;uid=0x23e1cee3;creduid=0x23e1cee3;pid=0x6c0
> > > >  Feb 23 12:22:51.878765 test-box.example.net cifs.upcall[1729]: ver=2
> > > > Feb 23 12:22:51.878769 test-box.example.net cifs.upcall[1729]:
> > > > host=win2k16-dfs1.example.net
> > > > Feb 23 12:22:51.878773 test-box.example.net cifs.upcall[1729]:
> > > > ip=192.168.124.132
> > > > Feb 23 12:22:51.878776 test-box.example.net cifs.upcall[1729]: sec=1
> > > > Feb 23 12:22:51.878780 test-box.example.net cifs.upcall[1729]: uid=602001123
> > > > Feb 23 12:22:51.878783 test-box.example.net cifs.upcall[1729]: \
> > > > creduid=602001123 Feb 23 12:22:51.878786 test-box.example.net \
> > > > cifs.upcall[1729]: pid=1728 Feb 23 12:22:51.879060 test-box.example.net \
> > > >                 cifs.upcall[1729]:
> > > > get_cachename_from_process_env: pathname=/proc/1728/environ
> > > > Feb 23 12:22:51.879799 test-box.example.net cifs.upcall[1729]:
> > > > get_existing_cc: default ccache is FILE:/tmp/krb5cc_602001123
> > > > Feb 23 12:22:51.879819 test-box.example.net cifs.upcall[1729]:
> > > > get_tgt_time: unable to get principal
> > > > Feb 23 12:22:51.879824 test-box.example.net cifs.upcall[1729]:
> > > > handle_krb5_mech: getting service ticket for win2k16-dfs1.example.net
> > > > Feb 23 12:22:51.879827 test-box.example.net cifs.upcall[1729]:
> > > > handle_krb5_mech: using GSS-API
> > > > Feb 23 12:22:51.886573 test-box.example.net gssproxy[1000]:
> > > > [2021/02/23 17:22:51]: Client [2021/02/23 17:22:51]:
> > > > (/usr/sbin/cifs.upcall) [2021/02/23 17:22:51]:  connected (fd =
> > > > 14)[2021/02/23 17:22:51]:  (pid = 1729) (uid = 602001123) (gid =
> > > > 602000513)[2021/02/23 17:22:51]:  (context =
> > > > system_u:system_r:kernel_t:s0)[>
> > > > Feb 23 12:22:51.886573 test-box.example.net gssproxy[1000]: [CID
> > > > 14][2021/02/23 17:22:51]: Connection matched service cifs
> > > > Feb 23 12:22:51.886573 test-box.example.net gssproxy[1000]: [CID
> > > > 14][2021/02/23 17:22:51]: gp_rpc_execute: executing 6
> > > > (GSSX_ACQUIRE_CRED) for service "cifs", euid: 602001123,socket:
> > > > /var/lib/gssproxy/cifs.sock
> > > > Feb 23 12:22:51.886573 test-box.example.net gssproxy[1000]:
> > > > GSSX_ARG_ACQUIRE_CRED( call_ctx: { "" [  ] } input_cred_handle: <Null>
> > > > add_cred: 0 desired_name: <Null> time_req: 0 desired_mechs: { }
> > > > cred_usage: INITIATE initiator_time_req: 0 acceptor_time_req: 0 )
> > > > Feb 23 12:22:52.346639 test-box.example.net gssproxy[1000]:
> > > > GSSX_RES_ACQUIRE_CRED( status: { 0 { 1 2 840 113554 1 2 2 } 0 "" "" [
> > > > ] } output_cred_handle: { "chang@EXAMPLE.NET" [ { "chang@EXAMPLE.NET"
> > > > { 1 2 840 113554 1 2 2 } INITIATE 36000 0 } ] [ K.....T.....pJv.... ]
> > > > 0 } )
> > > > Feb 23 12:22:52.348086 test-box.example.net gssproxy[1000]: [CID
> > > > 14][2021/02/23 17:22:52]: Connection matched service cifs
> > > > Feb 23 12:22:52.348086 test-box.example.net gssproxy[1000]: [CID
> > > > 14][2021/02/23 17:22:52]: gp_rpc_execute: executing 8
> > > > (GSSX_INIT_SEC_CONTEXT) for service "cifs", euid: 602001123,socket:
> > > > /var/lib/gssproxy/cifs.sock
> > > > Feb 23 12:22:52.348086 test-box.example.net gssproxy[1000]:
> > > > GSSX_ARG_INIT_SEC_CONTEXT( call_ctx: { "" [  ] } context_handle:
> > > > <Null> cred_handle: { "chang@EXAMPLE.NET" [ { "chang@EXAMPLE.NET" { 1
> > > > 2 840 113554 1 2 2 } INITIATE 36000 0 } ] [ K.....T.....pJv.... ] 0 }
> > > > target_name: "cifs@win2k16-dfs1.example.net" mech>
> > > > Feb 23 12:22:52.348086 test-box.example.net gssproxy[1000]: [CID
> > > > 14][2021/02/23 17:22:52]: Credentials allowed by configuration
> > > > Feb 23 12:22:52.357103 test-box.example.net gssproxy[1000]:
> > > > GSSX_RES_INIT_SEC_CONTEXT( status: { 0 { 1 2 840 113554 1 2 2 } 0 ""
> > > > "" [  ] } context_handle: { [ ......H............ ] [  ] 0 { 1 2 840
> > > > 113554 1 2 2 } "chang@EXAMPLE.NET"
> > > > "cifs/win2k16-dfs1.example.net@EXAMPLE.NET" 36000 432 1 1 }
> > > > output_token: [ .....>
> > > > Feb 23 12:22:52.357419 test-box.example.net cifs.upcall[1729]: Exit status 0
> > > > 
> > > > 
> > > > Ultimately a helper-script packaged with cifs-utils or a separate
> > > > package entirely could be responsible for adding the file under
> > > > /etc/gssproxy and the drop-in file for systemd. The helper script
> > > > could take a series of users/groups as arguments that would limit
> > > > access to the socket file or there could be a separate config file
> > > > that is read from to determine if access to the cifs.sock socket
> > > > should be limited.
> > > > 
> > > > 
> > > > On Fri, Feb 19, 2021 at 12:38 PM Simo Sorce <simo@redhat.com> wrote:
> > > > > On Fri, 2021-02-19 at 03:30 -0800, Shyam Prasad N wrote:
> > > > > > Hi Simo,
> > > > > > 
> > > > > > > Finally the GSS-Proxy mechanism is namespace compatible, so you also
> > > > > > > get the ability to define different auth daemons per different
> > > > > > > containers, no need to invent new mechanisms for that or change yet
> > > > > > > again protocols/userspace to obtain container capabilities.
> > > > > > 
> > > > > > Could you please point me to the documentation for doing this?
> > > > > 
> > > > > I do not know if the kernel documents this, but the way gssproxy works
> > > > > is that when you start the daemon it pokes at the kernel to let it know
> > > > > the socket is available. So then the kernel opens the socket in the
> > > > > namespace the proxy is running into (detected from the poking
> > > > > operation, which is a write in a proc file).
> > > > > 
> > > > > HTH,
> > > > > Simo.
> > > > > 
> > > > > > Regards,
> > > > > > Shyam
> > > > > > 
> > > > > > On Thu, Dec 17, 2020 at 5:41 AM Simo Sorce <simo@redhat.com> wrote:
> > > > > > > Hi Steve,
> > > > > > > 
> > > > > > > GSSAPI and krb5 as implemented in system krb5 libraries exists from
> > > > > > > longer than Samba has implemented those capabilities, I do not think it
> > > > > > > make sense to reason along those lines.
> > > > > > > 
> > > > > > > GSS-Proxy has been built with a protocol to talk from the kernel that
> > > > > > > resolved a number of issues for knfsd (eg big packet sizes when a MS-
> > > > > > > PAC is present).
> > > > > > > 
> > > > > > > And Samba uses internally exactly the same krb5 mechanism as it defers
> > > > > > > to the kerberos libraries as well.
> > > > > > > 
> > > > > > > Additionally GSS-Proxy can be very easily extended to also do NTLMSSP
> > > > > > > using the same interface as I have built the gssntlmssp long ago from
> > > > > > > the MS spec, and is probably the most correct NTLMSSP implementation
> > > > > > > you can find around.
> > > > > > > 
> > > > > > > Gssntlmssp also has a Winbind backend so you get automaticaly access to
> > > > > > > whatever cached credentials Winbindd has for users as a bonus (although
> > > > > > > the integration can be improved there), yet you *can* use it w/o
> > > > > > > Winbindd just fine providing a credential file (smbpasswd format
> > > > > > > compatible).
> > > > > > > 
> > > > > > > GSS-Proxy is already integrated in distributions because it is used by
> > > > > > > knfsd, and can be as easily used by cifsd, and you *should* really use
> > > > > > > it there, so we can have a single, consistent, maintained, mechanism
> > > > > > > for server side GSS authentication, and not have to repeat and reinvent
> > > > > > > kernel to userspace mechanisms.
> > > > > > > 
> > > > > > > And if you add it for cifsd you have yet another reason to do it for
> > > > > > > cifs.ko as well.
> > > > > > > 
> > > > > > > Finally the GSS-Proxy mechanism is namespace compatible, so you also
> > > > > > > get the ability to define different auth daemons per different
> > > > > > > containers, no need to invent new mechanisms for that or change yet
> > > > > > > again protocols/userspace to obtain container capabilities.
> > > > > > > 
> > > > > > > For the client we'll need to add some XDR parsing functions in kernel,
> > > > > > > they were omitted from my original patches because there was no client
> > > > > > > side kernel consumer back then, but it i an easy, mechanical change.
> > > > > > > 
> > > > > > > HTH,
> > > > > > > Simo.
> > > > > > > 
> > > > > > > On Wed, 2020-12-16 at 16:43 -0600, Steve French wrote:
> > > > > > > > generally I would feel more comfortable using something (library or
> > > > > > > > utility) in Samba (if needed) for additional SPNEGO support if
> > > > > > > > something is missing (in what the kernel drivers are doing to
> > > > > > > > encapsulate Active Directory or Samba AD krb5 tickets in SPNEGO) as
> > > > > > > > Samba is better maintained/tested etc. than most components.  Is \
> > > > > > > > there something in Samba that could be used here instead of having a
> > > > > > > > dependency on another project - Samba has been doing Kerberos/SPNEGO
> > > > > > > > longer than most ...?   There are probably others (jra, Metze etc.)
> > > > > > > > that have would know more about gssproxy vs. Samba equivalents though
> > > > > > > > and would defer to them ...
> > > > > > > > 
> > > > > > > > On Wed, Dec 16, 2020 at 8:33 AM Simo Sorce <simo@redhat.com> wrote:
> > > > > > > > > Hi Michael,
> > > > > > > > > as you say the best course of action would be for cifs.ko to move \
> > > > > > > > > to use the RPC interface we defined for knfsd (with any extensions \
> > > > > > > > > that may  be needed), and we had discussions in the past with cifs \
> > > > > > > > > upstream developers about it. But nothing really materialized.
> > > > > > > > > 
> > > > > > > > > If something is needed in the short term, I thjink the quickest \
> > > > > > > > > course of action is indeed to change the userspace helper to use \
> > > > > > > > > gssapi function calls, so that they can be intercepted like we do \
> > > > > > > > > for rpc.gssd (nfs client's userspace helper).
> > > > > > > > > 
> > > > > > > > > Unfortunately I do not have the cycles to work on that myself at \
> > > > > > > > > this time :-(
> > > > > > > > > 
> > > > > > > > > HTH,
> > > > > > > > > Simo.
> > > > > > > > > 
> > > > > > > > > On Wed, 2020-12-16 at 10:01 +0000, Weiser, Michael wrote:
> > > > > > > > > > Hello,
> > > > > > > > > > 
> > > > > > > > > > I have a use-case for authentication of Linux cifs client mounts \
> > > > > > > > > > without the user being present (e.g. from batch jobs) using \
> > > > > > > > > > gssproxy's impersonation feature with Kerberos Constrained \
> > > > > > > > > > Delegation similar to how it can be done for NFS[1]. 
> > > > > > > > > > My understanding is that currently neither the Linux cifs kernel \
> > > > > > > > > > client nor cifs-utils userland tools support acquiring \
> > > > > > > > > > credentials using gssproxy. The former uses a custom upcall \
> > > > > > > > > > interface to talk to cifs.spnego from cifs-utils. The latter then \
> > > > > > > > > > goes looking for Kerberos ticket caches using libkrb5 functions, \
> > > > > > > > > > not GSSAPI, which prevents gssproxy from interacting with it.[2] 
> > > > > > > > > > From what I understand, the preferred method would be to switch \
> > > > > > > > > > the Linux kernel client upcall to the RPC protocol defined by \
> > > > > > > > > > gssproxy[3] (as has been done for the Linux kernel NFS server \
> > > > > > > > > > already replacing rpc.svcgssd[4]). The kernel could then, at \
> > > > > > > > > > least optionally, talk to gssproxy directly to try and obtain \
> > > > > > > > > > credentials. 
> > > > > > > > > > Failing that, cifs-utils' cifs.spnego could be switched to GSSAPI \
> > > > > > > > > > so that gssproxy's interposer plugin could intercept GSSAPI calls \
> > > > > > > > > > and provide them with the required credentials (similar to the \
> > > > > > > > > > NFS client rpc.gssd[5]). 
> > > > > > > > > > Assuming my understanding is correct so far:
> > > > > > > > > > 
> > > > > > > > > > Is anyone doing any work on this and could use some help \
> > > > > > > > > > (testing, coding)? What would be expected complexity and possible \
> > > > > > > > > > roadblocks when trying to make a start at implementing this? Or \
> > > > > > > > > > is the idea moot due to some constraint or recent development I'm \
> > > > > > > > > > not aware of? 
> > > > > > > > > > I have found a recent discussion of the topic on linux-cifs[6] \
> > > > > > > > > > which provided no definite answer though. 
> > > > > > > > > > As a crude attempt at an explicit userspace workaround I tried \
> > > > > > > > > > but failed to trick smbclient into initialising a ticket cache \
> > > > > > > > > > using gssproxy for cifs.spnego to find later on. Is this \
> > > > > > > > > > something that could be implemented without too much redundant \
> > > > > > > > > > effort (or should already work, perhaps using a different tool)? 
> > > > > > > > > > [1] \
> > > > > > > > > > https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#user-impersonation-via-constrained-delegation
> > > > > > > > > >  [2] https://pagure.io/gssproxy/issue/56
> > > > > > > > > > [3] \
> > > > > > > > > > https://github.com/gssapi/gssproxy/blob/main/docs/ProtocolDocumentation.md
> > > > > > > > > >  [4] \
> > > > > > > > > > https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#nfs-server
> > > > > > > > > >  [5] \
> > > > > > > > > > https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#nfs-client
> > > > > > > > > >  [6] https://www.spinics.net/lists/linux-cifs/msg20182.html
> > > > > > > > > > --
> > > > > > > > > > Thanks,
> > > > > > > > > > Michael
> > > > > > > > > > _______________________________________________
> > > > > > > > > > gss-proxy mailing list -- gss-proxy@lists.fedorahosted.org
> > > > > > > > > > To unsubscribe send an email to \
> > > > > > > > > > gss-proxy-leave@lists.fedorahosted.org Fedora Code of Conduct: \
> > > > > > > > > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ \
> > > > > > > > > > List Guidelines: \
> > > > > > > > > > https://fedoraproject.org/wiki/Mailing_list_guidelines List \
> > > > > > > > > > Archives: \
> > > > > > > > > > https://lists.fedorahosted.org/archives/list/gss-proxy@lists.fedorahosted.org
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > --
> > > > > > > > > Simo Sorce
> > > > > > > > > RHEL Crypto Team
> > > > > > > > > Red Hat, Inc
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > 
> > > > > > > --
> > > > > > > Simo Sorce
> > > > > > > RHEL Crypto Team
> > > > > > > Red Hat, Inc
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > 
> > > > > --
> > > > > Simo Sorce
> > > > > RHEL Crypto Team
> > > > > Red Hat, Inc
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > 
> > > --
> > > Simo Sorce
> > > RHEL Crypto Team
> > > Red Hat, Inc
> > > 
> > > 
> > > 
> > > 
> 
> --
> Simo Sorce
> RHEL Crypto Team
> Red Hat, Inc
> 
> 
> 
> 


[prev in list] [next in list] [prev in thread] [next in thread]