> I don't think moving parts of the user configuration out of the config
files is acceptable, and if you disable and then re-enable a module, I
don't see any reason that the config options *should* be sticky.
I wasn't so much proposing an alternative, just going over the
shortcomings I see of this
On Sat, May 15, 2010 at 12:31:18AM -, Daniel Richard G. wrote:
> This is a potential solution, but putting aside the tricky case of "what
> happens if the common-* files have customized options, and then the PAM
> profile changes?", another problem with this approach is the fragility
> of the
Happy to give it a try, Steve. I just commented in that bug report.
This is a potential solution, but putting aside the tricky case of "what
happens if the common-* files have customized options, and then the PAM
profile changes?", another problem with this approach is the fragility
of the customi
Daniel,
I've opened a separate bug, bug #579826, to track the problem with pam-
auth-update not saving changes to the pam_krb5 module options. Would
you mind testing the libpam-runtime 1.1.1-2ubuntu3 package in lucid-
proposed and reporting on that bug whether it solves the problem for you
(speci
On Tue, Apr 13, 2010 at 07:41:04AM -, Daniel Richard G. wrote:
> > No, it's persistent unless you disable pam_krb5 entirely. Have you
> tried it?
> Yeah, where pam-auth-update asks you "Override local changes to
> /etc/pam.d/common-*?" I see the man page says something about preserving
> modul
> Er, how is it silent when pam-auth-update asks you a question?
Silent, in the sense that when you run p-a-u, it doesn't indicate that
the common-* files have been modified in any way; it just presents you
with the same checkbox-list of profiles. You leave everything as-is, hit
OK, look at the fi
"Daniel Richard G." writes:
> For that matter, has there been any talk on a better way doing
> krb5.conf, like doing a /etc/krb5.conf.d/ or a krb5-auth-update(8) or
> the like?
Debian Bug#429692. There's no progress on it so far as I know. I should
look at adding something like that to Heimdal
"Daniel Richard G." writes:
> Yeah, where pam-auth-update asks you "Override local changes to
> /etc/pam.d/common-*?" I see the man page says something about preserving
> module options, but if I add an option to (say) common-auth, and re-run
> p-a-u, the option is silently blown away.
Er, how i
> No, it's persistent unless you disable pam_krb5 entirely. Have you
tried it?
Yeah, where pam-auth-update asks you "Override local changes to
/etc/pam.d/common-*?" I see the man page says something about preserving
module options, but if I add an option to (say) common-auth, and re-run
p-a-u, the
On Tue, Apr 13, 2010 at 06:58:02AM -, Daniel Richard G. wrote:
> Fair enough, though I hope you're not suggesting direct modification of
> the /etc/pam.d/common-* files as a practical way of doing site
> customization. (That'll work fine until the next time someone wants to
> run pam-auth-upda
On Tue, Apr 13, 2010 at 06:48:21AM -, Daniel Richard G. wrote:
> krb5.conf is a config file under /etc.
/etc/pam.d/common-* are also config files under /etc.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I c
> They may want to, but I don't think the added complexity of debconf
solely for what I believe is a rarely-used option makes sense. [...] I
don't think debconf offers much benefit here.
Fair enough, though I hope you're not suggesting direct modification of
the /etc/pam.d/common-* files as a prac
> I guess I'm a bit baffled by why fixing your PAM configuration is a
workaround but installing a custom krb5.conf is a desired configuration
step.
krb5.conf is a config file under /etc. That's the ideal place to make
configuration changes. As it is, right now, adding the minimum_uid bit
involves
On Tue, Apr 13, 2010 at 04:42:37AM -, Daniel Richard G. wrote:
> > But I suppose that's what NEWS.Debian is for.
> You could also stick in a debconf notice, like what x11-common had for a
> while ("Major possible upgrade issues").
This is not considered good practice, and I don't think it's w
"Daniel Richard G." writes:
> At the moment, my PAM-profile override *is* put into place by the same
> script that adds the minimum_uid bit to krb5.conf. But that's just a
> workaround. I don't need a workaround; I need a fix for this, so that I
> can toss the workaround :-)
I guess I'm a bit ba
> But I suppose that's what NEWS.Debian is for.
You could also stick in a debconf notice, like what x11-common had for a
while ("Major possible upgrade issues").
> Right -- if you're already distributing a krb5.conf with this setting,
surely the same mechanism could be used to override the PAM
co
Steve Langasek writes:
> Honestly, I don't see any good choices at the packaging level for
> permuting the pam_krb5 options used.
Yeah, that's what it was looking like to me as well.
> Why wouldn't it work to have krb5-config do a one-time adjustment of
> /etc/krb5.conf on upgrade (w/ version g
Isn't it possible to use debconf to change around the enabled profiles,
via the libpam-runtime/profiles selection?
Steve: I'm not sure I understand what you mean by "automatically apply
... by the same mechanism." I can set minimum_uid in krb5.conf, but I
also have to toss the minimum_uid= options
On Wed, Mar 31, 2010 at 05:06:48AM -, Russ Allbery wrote:
> No, it's not a conffile. The generated /etc/pam.d files are configuration
> files, but if the user is using the defaults, I believe changes to the
> defaults are just automatically applied (although Steve would know better
> than I).
"Daniel Richard G." writes:
> How did PAM-related packages manage changes to /etc/pam.d/* before pam-
> auth-update came along? Yeah, automated editing is gauche, but it's not
> like you just can't do *anything* in that sort of scenario...
Doing nothing is exactly what they did, so far as I know
"Daniel Richard G." writes:
> Thought about the upgrade process a bit. How about this:
> 1. kerberos-configs starts generating new krb5.conf files with
> minimum_uid=1000. Then a little later...
> 2. libpam-krb5 has minimum_uid removed from pam-configs/krb5. On
> upgrade, it checks to see if th
Thought about the upgrade process a bit. How about this:
1. kerberos-configs starts generating new krb5.conf files with
minimum_uid=1000. Then a little later...
2. libpam-krb5 has minimum_uid removed from pam-configs/krb5. On
upgrade, it checks to see if this is in krb5.conf. If yes, great. If no
You can see why I'm pushing on this. It's pay now, or pay later... no
real gain in waiting :-]
Ah, yes, users who've been dist-upgrading their Ubuntu installs since
Warty... I guess there's no such thing as "temporary" postinst logic, if
those need to be handled.
A warning wouldn't be so bad. The
"Daniel Richard G." writes:
> What about just punting on upgrades altogether, and putting in the
> rearranged config only on a new install? Could that be done with
> appropriate postinst magic?
The tricky part is coordination. At what point can libpam-krb5 drop the
minimum_uid setting and assum
What about just punting on upgrades altogether, and putting in the
rearranged config only on a new install? Could that be done with
appropriate postinst magic?
Alternately, you could pop up a big scary debconf warning... there's
ample precedent for that.
--
Why is /usr/share/pam-configs/krb5 spe
"Daniel Richard G." writes:
> No no, the goal is not to have Kerberos users with uid < 1000. It's to
> push minimum_uid higher, so that you can have normal 1000-something-uid
> local users authenticate without any Kerberos interaction. Same argument
> as for the root user and ignore_root.
Oh, so
No no, the goal is not to have Kerberos users with uid < 1000. It's to
push minimum_uid higher, so that you can have normal 1000-something-uid
local users authenticate without any Kerberos interaction. Same argument
as for the root user and ignore_root.
As for doing the upgrade, isn't pam-configs/
"Daniel Richard G." writes:
> I know this isn't a big deal in the larger scheme of things, but it's
> the difference between being able to use the stock krb5 profile, and
> having to maintain a custom one. (And remember, the current behavior
> involves headaches if you have any non-root local use
I know this isn't a big deal in the larger scheme of things, but it's
the difference between being able to use the stock krb5 profile, and
having to maintain a custom one. (And remember, the current behavior
involves headaches if you have any non-root local users.)
Please bring this up with Sam wh
"Daniel Richard G." writes:
> Can we get minimum_uid out of pam-configs/krb5 for Lucid?
I haven't had a chance to discuss the idea with the other kerberos-configs
maintainer, and at the moment this is a low priority for me since I think
the current behavior is correct.
At the moment, therefore,
Can we get minimum_uid out of pam-configs/krb5 for Lucid?
--
Why is /usr/share/pam-configs/krb5 specifying minimum_uid= ?
https://bugs.launchpad.net/bugs/369575
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to kerberos-configs in ubuntu.
-
minimum_uid in krb5.conf, and ignore_root in .../pam-configs/krb5 sounds
like a good way to go. For sites that distribute a global krb5.conf,
they can always add the minimum_uid option if they like---if it's not
already there, the distribution is likely passing that in as a PAM
module option anyway
Steve Langasek writes:
> But it would also be reasonable to set this default via appdefaults in
> /etc/krb5.conf, which I didn't know was possible - if that were done
> in the default krb5.conf, then we could drop the module option from
> /usr/share/pam/configs/krb5. So I'll mark this bug as inv
Hi Daniel,
> Why is /usr/share/pam-configs/krb5 specifying minimum_uid= ?
Because this is the correct default minimum_uid value to use on Ubuntu
systems, where 1000 marks the boundary between system and user accounts,
and this default has not been otherwise specified.
> The problem is that some
34 matches
Mail list logo
