Commit 2f682f25c642fcfe7c511d04bc9d67e732282348 changed existing
behavior to avoid a deadlock for users using Kerberized NFS home dirs.
However, this also prevents users leveraging their own k5identity
files under their home directory and instead rpc.gssd uses a
system-wide /.k5identity file. For users expecting to use their own
k5identity file this is certainly unexpected.
Below is some pseudo code that was proposed and would just add a flag
allowing for the behavior prior to
2f682f25c642fcfe7c511d04bc9d67e732282348:
/* psudo code snippet starts here */
/*
* Some krb5 routines try to scrape info out of files in the user's
* home directory. This can easily deadlock when that homedir is on a
- * kerberized NFS mount. By setting $HOME unconditionally to "/", we
+ * kerberized NFS mount. Some users may not have $HOME on NFS.
+ * By default setting $HOME unconditionally to "/", we
* prevent this behavior in routines that use $HOME in preference to
* the results of getpw*.
+ * Users who have $HOME on krb5-NFS should set
`--home-not-kerberized` in argv
+ * Users who have $HOME on krb5-NFS but want to use their
$HOME anyway should set NFS_HOME_ACCESSIBLE=TRUE
*/
+ if (argv == '--home-not-kerberized') ||
(getenv("NFS_HOME_ACCESSIBLE") == 'TRUE') {
+ log.debug('Not masking $HOME, this breaks on Kerberized $HOME');
+ }
+ else {
+ log.debug('Assuming $HOME requires Kerberos, use
`--home-not-kerberized` to change this behavior');
if (setenv("HOME", "/", 1)) {
printerr(1, "Unable to set $HOME: %s\n", strerror(errn));
exit(1);
}
+ }
/* psudo code snippet ends here */
While acknowledging the use of this flag for Kerberized NFS home dirs
is undesirable and would cause a deadlock, there should be no issue
for users not using Kerberized NFS home dirs.
Does anyone consider adding the above proposed flag as being problematic?
Hello,
Sorry for the delayed response... Trying to burn up some PTO.
On 11/23/20 1:17 PM, Jacob Shivers wrote:
> Commit 2f682f25c642fcfe7c511d04bc9d67e732282348 changed existing
> behavior to avoid a deadlock for users using Kerberized NFS home dirs.
>
> However, this also prevents users leveraging their own k5identity
> files under their home directory and instead rpc.gssd uses a
> system-wide /.k5identity file. For users expecting to use their own
> k5identity file this is certainly unexpected.
So how is the deadlock not happening when ~/.k5identity is on a NFS
home directory? What am I missing?
>
> Below is some pseudo code that was proposed and would just add a flag
> allowing for the behavior prior to
> 2f682f25c642fcfe7c511d04bc9d67e732282348:
>
> /* psudo code snippet starts here */
> /*
> * Some krb5 routines try to scrape info out of files in the user's
> * home directory. This can easily deadlock when that homedir is on a
> - * kerberized NFS mount. By setting $HOME unconditionally to "/", we
> + * kerberized NFS mount. Some users may not have $HOME on NFS.
> + * By default setting $HOME unconditionally to "/", we
> * prevent this behavior in routines that use $HOME in preference to
> * the results of getpw*.
> + * Users who have $HOME on krb5-NFS should set
> `--home-not-kerberized` in argv
> + * Users who have $HOME on krb5-NFS but want to use their
> $HOME anyway should set NFS_HOME_ACCESSIBLE=TRUE
> */
> + if (argv == '--home-not-kerberized') ||
> (getenv("NFS_HOME_ACCESSIBLE") == 'TRUE') {
> + log.debug('Not masking $HOME, this breaks on Kerberized $HOME');
> + }
> + else {
> + log.debug('Assuming $HOME requires Kerberos, use
> `--home-not-kerberized` to change this behavior');
> if (setenv("HOME", "/", 1)) {
> printerr(1, "Unable to set $HOME: %s\n", strerror(errn));
> exit(1);
> }
> + }
> /* psudo code snippet ends here */
In general I'm pretty reluctant to add flags but what is needed
to do so is a company single letter flag '-H' and a man page
entry describing the flag.
>
> While acknowledging the use of this flag for Kerberized NFS home dirs
> is undesirable and would cause a deadlock, there should be no issue
> for users not using Kerberized NFS home dirs.
What apps are you using that is seeing this problem?
steved.
Hello,
I completely missed this so please excuse the delay.
> On 11/23/20 1:17 PM, Jacob Shivers wrote:
> > Commit 2f682f25c642fcfe7c511d04bc9d67e732282348 changed existing
> > behavior to avoid a deadlock for users using Kerberized NFS home dirs.
> >
> > However, this also prevents users leveraging their own k5identity
> > files under their home directory and instead rpc.gssd uses a
> > system-wide /.k5identity file. For users expecting to use their own
> > k5identity file this is certainly unexpected.
> So how is the deadlock not happening when ~/.k5identity is on a NFS
> home directory? What am I missing?
They are not using NFS for home directories. They are accessing
systems with a local fs backing the /home
> > Below is some pseudo code that was proposed and would just add a flag
> > allowing for the behavior prior to
> > 2f682f25c642fcfe7c511d04bc9d67e732282348:
> >
> > /* psudo code snippet starts here */
> > /*
> > * Some krb5 routines try to scrape info out of files in the user's
> > * home directory. This can easily deadlock when that homedir is on a
> > - * kerberized NFS mount. By setting $HOME unconditionally to "/", we
> > + * kerberized NFS mount. Some users may not have $HOME on NFS.
> > + * By default setting $HOME unconditionally to "/", we
> > * prevent this behavior in routines that use $HOME in preference to
> > * the results of getpw*.
> > + * Users who have $HOME on krb5-NFS should set
> > `--home-not-kerberized` in argv
> > + * Users who have $HOME on krb5-NFS but want to use their
> > $HOME anyway should set NFS_HOME_ACCESSIBLE=TRUE
> > */
> > + if (argv == '--home-not-kerberized') ||
> > (getenv("NFS_HOME_ACCESSIBLE") == 'TRUE') {
> > + log.debug('Not masking $HOME, this breaks on Kerberized $HOME');
> > + }
> > + else {
> > + log.debug('Assuming $HOME requires Kerberos, use
> > `--home-not-kerberized` to change this behavior');
> > if (setenv("HOME", "/", 1)) {
> > printerr(1, "Unable to set $HOME: %s\n", strerror(errn));
> > exit(1);
> > }
> > + }
> > /* psudo code snippet ends here */
> In general I'm pretty reluctant to add flags but what is needed
> to do so is a company single letter flag '-H' and a man page
> entry describing the flag.
Ok.
> >
> > While acknowledging the use of this flag for Kerberized NFS home dirs
> > is undesirable and would cause a deadlock, there should be no issue
> > for users not using Kerberized NFS home dirs.
> What apps are you using that is seeing this problem?
It is just when accessing the Kerberized NFS share. Other Kerberos
aware services/applications check for the existence of ~/.k5identify
before reading /var/kerberos/krb5/user/${EUID}/client.keytab. rpc.gssd
no longer does this and the intent of the patch would be to add
granularity to choose the behavior or rpc.gssd with respect to
scanning for a k5identity file.
If any additional information is required, please inform me.
Thanks,
Jacob Shivers
Patches that include a '-H' flag and man page entry.
The default is to maintain behavior since
2f682f25c642fcfe7c511d04bc9d67e732282348, but passing '-H' avoids
$HOME being set to '/'.
Also included a patch for /etc/nfs.conf to add 'set-home=1'. Setting
it to false is equivalent to passing '-H' to rpc.gssd.
Regards,
Jacob Shivers
On Mon, Jan 4, 2021 at 11:00 AM Jacob Shivers <[email protected]> wrote:
>
> Hello,
>
> I completely missed this so please excuse the delay.
>
> > On 11/23/20 1:17 PM, Jacob Shivers wrote:
> > > Commit 2f682f25c642fcfe7c511d04bc9d67e732282348 changed existing
> > > behavior to avoid a deadlock for users using Kerberized NFS home dirs.
> > >
> > > However, this also prevents users leveraging their own k5identity
> > > files under their home directory and instead rpc.gssd uses a
> > > system-wide /.k5identity file. For users expecting to use their own
> > > k5identity file this is certainly unexpected.
> > So how is the deadlock not happening when ~/.k5identity is on a NFS
> > home directory? What am I missing?
> They are not using NFS for home directories. They are accessing
> systems with a local fs backing the /home
>
> > > Below is some pseudo code that was proposed and would just add a flag
> > > allowing for the behavior prior to
> > > 2f682f25c642fcfe7c511d04bc9d67e732282348:
> > >
> > > /* psudo code snippet starts here */
> > > /*
> > > * Some krb5 routines try to scrape info out of files in the user's
> > > * home directory. This can easily deadlock when that homedir is on a
> > > - * kerberized NFS mount. By setting $HOME unconditionally to "/", we
> > > + * kerberized NFS mount. Some users may not have $HOME on NFS.
> > > + * By default setting $HOME unconditionally to "/", we
> > > * prevent this behavior in routines that use $HOME in preference to
> > > * the results of getpw*.
> > > + * Users who have $HOME on krb5-NFS should set
> > > `--home-not-kerberized` in argv
> > > + * Users who have $HOME on krb5-NFS but want to use their
> > > $HOME anyway should set NFS_HOME_ACCESSIBLE=TRUE
> > > */
> > > + if (argv == '--home-not-kerberized') ||
> > > (getenv("NFS_HOME_ACCESSIBLE") == 'TRUE') {
> > > + log.debug('Not masking $HOME, this breaks on Kerberized $HOME');
> > > + }
> > > + else {
> > > + log.debug('Assuming $HOME requires Kerberos, use
> > > `--home-not-kerberized` to change this behavior');
> > > if (setenv("HOME", "/", 1)) {
> > > printerr(1, "Unable to set $HOME: %s\n", strerror(errn));
> > > exit(1);
> > > }
> > > + }
> > > /* psudo code snippet ends here */
> > In general I'm pretty reluctant to add flags but what is needed
> > to do so is a company single letter flag '-H' and a man page
> > entry describing the flag.
> Ok.
>
> > >
> > > While acknowledging the use of this flag for Kerberized NFS home dirs
> > > is undesirable and would cause a deadlock, there should be no issue
> > > for users not using Kerberized NFS home dirs.
> > What apps are you using that is seeing this problem?
> It is just when accessing the Kerberized NFS share. Other Kerberos
> aware services/applications check for the existence of ~/.k5identify
> before reading /var/kerberos/krb5/user/${EUID}/client.keytab. rpc.gssd
> no longer does this and the intent of the patch would be to add
> granularity to choose the behavior or rpc.gssd with respect to
> scanning for a k5identity file.
>
> If any additional information is required, please inform me.
>
> Thanks,
>
> Jacob Shivers
I was talking to Jake and I think he will submit this again without
attachments so it's a little easier to review.
On Mon, Mar 1, 2021 at 12:07 PM Jacob Shivers <[email protected]> wrote:
>
> Patches that include a '-H' flag and man page entry.
>
> The default is to maintain behavior since
> 2f682f25c642fcfe7c511d04bc9d67e732282348, but passing '-H' avoids
> $HOME being set to '/'.
> Also included a patch for /etc/nfs.conf to add 'set-home=1'. Setting
> it to false is equivalent to passing '-H' to rpc.gssd.
>
> Regards,
>
> Jacob Shivers
>
> On Mon, Jan 4, 2021 at 11:00 AM Jacob Shivers <[email protected]> wrote:
> >
> > Hello,
> >
> > I completely missed this so please excuse the delay.
> >
> > > On 11/23/20 1:17 PM, Jacob Shivers wrote:
> > > > Commit 2f682f25c642fcfe7c511d04bc9d67e732282348 changed existing
> > > > behavior to avoid a deadlock for users using Kerberized NFS home dirs.
> > > >
> > > > However, this also prevents users leveraging their own k5identity
> > > > files under their home directory and instead rpc.gssd uses a
> > > > system-wide /.k5identity file. For users expecting to use their own
> > > > k5identity file this is certainly unexpected.
> > > So how is the deadlock not happening when ~/.k5identity is on a NFS
> > > home directory? What am I missing?
> > They are not using NFS for home directories. They are accessing
> > systems with a local fs backing the /home
> >
> > > > Below is some pseudo code that was proposed and would just add a flag
> > > > allowing for the behavior prior to
> > > > 2f682f25c642fcfe7c511d04bc9d67e732282348:
> > > >
> > > > /* psudo code snippet starts here */
> > > > /*
> > > > * Some krb5 routines try to scrape info out of files in the user's
> > > > * home directory. This can easily deadlock when that homedir is on a
> > > > - * kerberized NFS mount. By setting $HOME unconditionally to "/", we
> > > > + * kerberized NFS mount. Some users may not have $HOME on NFS.
> > > > + * By default setting $HOME unconditionally to "/", we
> > > > * prevent this behavior in routines that use $HOME in preference to
> > > > * the results of getpw*.
> > > > + * Users who have $HOME on krb5-NFS should set
> > > > `--home-not-kerberized` in argv
> > > > + * Users who have $HOME on krb5-NFS but want to use their
> > > > $HOME anyway should set NFS_HOME_ACCESSIBLE=TRUE
> > > > */
> > > > + if (argv == '--home-not-kerberized') ||
> > > > (getenv("NFS_HOME_ACCESSIBLE") == 'TRUE') {
> > > > + log.debug('Not masking $HOME, this breaks on Kerberized $HOME');
> > > > + }
> > > > + else {
> > > > + log.debug('Assuming $HOME requires Kerberos, use
> > > > `--home-not-kerberized` to change this behavior');
> > > > if (setenv("HOME", "/", 1)) {
> > > > printerr(1, "Unable to set $HOME: %s\n", strerror(errn));
> > > > exit(1);
> > > > }
> > > > + }
> > > > /* psudo code snippet ends here */
> > > In general I'm pretty reluctant to add flags but what is needed
> > > to do so is a company single letter flag '-H' and a man page
> > > entry describing the flag.
> > Ok.
> >
> > > >
> > > > While acknowledging the use of this flag for Kerberized NFS home dirs
> > > > is undesirable and would cause a deadlock, there should be no issue
> > > > for users not using Kerberized NFS home dirs.
> > > What apps are you using that is seeing this problem?
> > It is just when accessing the Kerberized NFS share. Other Kerberos
> > aware services/applications check for the existence of ~/.k5identify
> > before reading /var/kerberos/krb5/user/${EUID}/client.keytab. rpc.gssd
> > no longer does this and the intent of the patch would be to add
> > granularity to choose the behavior or rpc.gssd with respect to
> > scanning for a k5identity file.
> >
> > If any additional information is required, please inform me.
> >
> > Thanks,
> >
> > Jacob Shivers
On 3/1/21 1:54 PM, David Wysochanski wrote:
> I was talking to Jake and I think he will submit this again without
> attachments so it's a little easier to review.
Thank you!
steved.
>
> On Mon, Mar 1, 2021 at 12:07 PM Jacob Shivers <[email protected]> wrote:
>>
>> Patches that include a '-H' flag and man page entry.
>>
>> The default is to maintain behavior since
>> 2f682f25c642fcfe7c511d04bc9d67e732282348, but passing '-H' avoids
>> $HOME being set to '/'.
>> Also included a patch for /etc/nfs.conf to add 'set-home=1'. Setting
>> it to false is equivalent to passing '-H' to rpc.gssd.
>>
>> Regards,
>>
>> Jacob Shivers
>>
>> On Mon, Jan 4, 2021 at 11:00 AM Jacob Shivers <[email protected]> wrote:
>>>
>>> Hello,
>>>
>>> I completely missed this so please excuse the delay.
>>>
>>>> On 11/23/20 1:17 PM, Jacob Shivers wrote:
>>>>> Commit 2f682f25c642fcfe7c511d04bc9d67e732282348 changed existing
>>>>> behavior to avoid a deadlock for users using Kerberized NFS home dirs.
>>>>>
>>>>> However, this also prevents users leveraging their own k5identity
>>>>> files under their home directory and instead rpc.gssd uses a
>>>>> system-wide /.k5identity file. For users expecting to use their own
>>>>> k5identity file this is certainly unexpected.
>>>> So how is the deadlock not happening when ~/.k5identity is on a NFS
>>>> home directory? What am I missing?
>>> They are not using NFS for home directories. They are accessing
>>> systems with a local fs backing the /home
>>>
>>>>> Below is some pseudo code that was proposed and would just add a flag
>>>>> allowing for the behavior prior to
>>>>> 2f682f25c642fcfe7c511d04bc9d67e732282348:
>>>>>
>>>>> /* psudo code snippet starts here */
>>>>> /*
>>>>> * Some krb5 routines try to scrape info out of files in the user's
>>>>> * home directory. This can easily deadlock when that homedir is on a
>>>>> - * kerberized NFS mount. By setting $HOME unconditionally to "/", we
>>>>> + * kerberized NFS mount. Some users may not have $HOME on NFS.
>>>>> + * By default setting $HOME unconditionally to "/", we
>>>>> * prevent this behavior in routines that use $HOME in preference to
>>>>> * the results of getpw*.
>>>>> + * Users who have $HOME on krb5-NFS should set
>>>>> `--home-not-kerberized` in argv
>>>>> + * Users who have $HOME on krb5-NFS but want to use their
>>>>> $HOME anyway should set NFS_HOME_ACCESSIBLE=TRUE
>>>>> */
>>>>> + if (argv == '--home-not-kerberized') ||
>>>>> (getenv("NFS_HOME_ACCESSIBLE") == 'TRUE') {
>>>>> + log.debug('Not masking $HOME, this breaks on Kerberized $HOME');
>>>>> + }
>>>>> + else {
>>>>> + log.debug('Assuming $HOME requires Kerberos, use
>>>>> `--home-not-kerberized` to change this behavior');
>>>>> if (setenv("HOME", "/", 1)) {
>>>>> printerr(1, "Unable to set $HOME: %s\n", strerror(errn));
>>>>> exit(1);
>>>>> }
>>>>> + }
>>>>> /* psudo code snippet ends here */
>>>> In general I'm pretty reluctant to add flags but what is needed
>>>> to do so is a company single letter flag '-H' and a man page
>>>> entry describing the flag.
>>> Ok.
>>>
>>>>>
>>>>> While acknowledging the use of this flag for Kerberized NFS home dirs
>>>>> is undesirable and would cause a deadlock, there should be no issue
>>>>> for users not using Kerberized NFS home dirs.
>>>> What apps are you using that is seeing this problem?
>>> It is just when accessing the Kerberized NFS share. Other Kerberos
>>> aware services/applications check for the existence of ~/.k5identify
>>> before reading /var/kerberos/krb5/user/${EUID}/client.keytab. rpc.gssd
>>> no longer does this and the intent of the patch would be to add
>>> granularity to choose the behavior or rpc.gssd with respect to
>>> scanning for a k5identity file.
>>>
>>> If any additional information is required, please inform me.
>>>
>>> Thanks,
>>>
>>> Jacob Shivers
>