Re: PAM: SSH: reject login when homdir does not exist?
On dg., abr. 17 2022, FreeBSD User wrote: Hello fellows, happy Easter! I run into a security issue this morning here and tried to look for a solution. We use OpenLDAP for all "regular users" login on hosts and web services. Authentication is required from some cloud/moodle services via LDAP, but some users not having any homedirectory on any machine within the domain will still be allowed to login, even if the home dir is not present. They get loged in onto the root of the filesystem, when login via SSH. Is there a way to prohibit login if homedir isn't present? Can you point me to the right place (PAM or something, pam_env isn't available on FreeBSD)? If this is a trivial issue and caused by lack of my personell knowledge, please excuse. Kind regards, Hey, even if you manage to do that, you probably shouldn't address your problem this way: existence of a directory is a rather weak assertion to make when deciding whether or not someone should be able to get a shell. Take a look at AllowGroups and AllowUsers in man 5 sshd_config, that should fit your use-case much better. Other than that, you probably want to change their shell and stuff like that. Do check: https://docs.freebsd.org/en/books/handbook/security/#security-intro And adapt to your LDAP setup. Also, mid-term this M.W. Lucas' Absolute FreeBSD is a really good place to learn things: https://mwl.io/nonfiction/os#af3e PS: This mailing list is for things related to FreeBSD-CURRENT; it seems like this question might be a better fit for freebsd-questions@, since it is related to systems in general. Cheers, -- Evilham
PAM: SSH: reject login when homdir does not exist?
Hello fellows, happy Easter! I run into a security issue this morning here and tried to look for a solution. We use OpenLDAP for all "regular users" login on hosts and web services. Authentication is required from some cloud/moodle services via LDAP, but some users not having any homedirectory on any machine within the domain will still be allowed to login, even if the home dir is not present. They get loged in onto the root of the filesystem, when login via SSH. Is there a way to prohibit login if homedir isn't present? Can you point me to the right place (PAM or something, pam_env isn't available on FreeBSD)? If this is a trivial issue and caused by lack of my personell knowledge, please excuse. Kind regards, O. Hartmann
Re: PAM module for loading ZFS keys on login
Konstantin Belousov wrote in : |On Mon, Sep 06, 2021 at 04:01:37PM +0200, Steffen Nurpmeso wrote: |> Eric McCorkle wrote in |> : |>|Interesting, I wasn't aware of the upstream module. I'd say that's |> |> It's existence was the reason i have readded (now optional, and |> a tad different) session support for my pam_xdg PAM module, |> because i was thinking that, if such a many-eyes-seen thing of |> a software project that claims to be and aims at being enterprise, |> ships such a terrible and terribly broken thing, then i can also |> offer session tracking. But my manual at least states |> |> CAVEATS |>On Unix systems any “daemonized” program or script is reparented \ |>to the |>program running with PID 1, most likely leaving the PAM user \ |>session |>without PAM recognizing this. Yet careless such code may \ ... |If you use reaper facility, that would ensure that all (grand-)children |of your session are always reparented to the reaper and not to init. In |other words, you can reliable know when the session ends. See |procctl(2) PROC_REAP_* commands. | |I believe that reaper-like functionality is available on all current |Unix-like systems, even if under different names. Ah it is really, really cool what becomes possible (everywhere;)! So (Open)PAM should maybe (configurably) enable this does for all programs which actually use modules which use session management. #?0|kent:free-src.git$ git grep PROC_REAP_ origin/main | grep -vE '\.2:|:tests/' | sed -E 's/^(.+:.+):.+$/\1/' | sort -u origin/main:sys/compat/freebsd32/freebsd32_misc.c origin/main:sys/kern/kern_procctl.c origin/main:sys/sys/procctl.h origin/main:usr.bin/timeout/timeout.c I do not have systemd here, but on Linux situation seems similar: #?0|kent:x$ tar -xf /x/balls/shadow/shadow-4.8.1.tar.xz #?0|kent:x$ grep -r REAP shadow-4.8.1/ #?1|kent:x$ tar -xf /x/balls/linux-pam/Linux-PAM-1.5.1.tar.xz #?0|kent:x$ grep -r REAP Linux-PAM-1.5.1/ [yes, pam_unix defines UNIX_REAP, not PR_SET_CHILD_SUBREAPER] #?0|kent:x$ tar -xf /x/balls/openssh/openssh-8.7p1.tar.gz #?0|kent:x$ grep -r REAP openssh-8.7p1/ #?1|kent:x$ Maybe this is why systemd flies, i would guess it does, and this gives you then reliable session management. I did not really know that actually, .. consciously. This is really cool, but still also that upstream OpenZFS module, and my one, and who knows which other PAM module also, perform really bad sad and bitter session counting via counter files, ... but that is a different topic. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: PAM module for loading ZFS keys on login
On Mon, Sep 06, 2021 at 04:01:37PM +0200, Steffen Nurpmeso wrote: > Eric McCorkle wrote in > : > |Interesting, I wasn't aware of the upstream module. I'd say that's > > It's existence was the reason i have readded (now optional, and > a tad different) session support for my pam_xdg PAM module, > because i was thinking that, if such a many-eyes-seen thing of > a software project that claims to be and aims at being enterprise, > ships such a terrible and terribly broken thing, then i can also > offer session tracking. But my manual at least states > > CAVEATS >On Unix systems any “daemonized” program or script is reparented to the >program running with PID 1, most likely leaving the PAM user session >without PAM recognizing this. Yet careless such code may hold or > expect >availability of resources of the session it just left, truly performing >cleanup when sessions end seems thus unwise. Since so many PAM modules >do support session tracking and cleanup pam_xdg.so readded optional > sup‐ >port for this. If you use reaper facility, that would ensure that all (grand-)children of your session are always reparented to the reaper and not to init. In other words, you can reliable know when the session ends. See procctl(2) PROC_REAP_* commands. I believe that reaper-like functionality is available on all current Unix-like systems, even if under different names. > > But the real solution would be PAM session tracking in-kernel, > somehow, wouldn't it? > Also, on FreeBSD and OpenPAM many separate files exist in > /etc/pam.d for things which might open a session, whereas linuxpam > at least has /etc/pam.d/common-session; it has many common- things > in fact, and in /etc/pam.d/sshd i for example see > > # > # /etc/pam.d/sshd - openssh service module configuration > # > > authinclude common-auth > > account include common-account > > passwordinclude common-password > > session include common-session > > --steffen > | > |Der Kragenbaer,The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) >
Re: PAM module for loading ZFS keys on login
Eric McCorkle wrote in : |Interesting, I wasn't aware of the upstream module. I'd say that's It's existence was the reason i have readded (now optional, and a tad different) session support for my pam_xdg PAM module, because i was thinking that, if such a many-eyes-seen thing of a software project that claims to be and aims at being enterprise, ships such a terrible and terribly broken thing, then i can also offer session tracking. But my manual at least states CAVEATS On Unix systems any “daemonized” program or script is reparented to the program running with PID 1, most likely leaving the PAM user session without PAM recognizing this. Yet careless such code may hold or expect availability of resources of the session it just left, truly performing cleanup when sessions end seems thus unwise. Since so many PAM modules do support session tracking and cleanup pam_xdg.so readded optional sup‐ port for this. But the real solution would be PAM session tracking in-kernel, somehow, wouldn't it? Also, on FreeBSD and OpenPAM many separate files exist in /etc/pam.d for things which might open a session, whereas linuxpam at least has /etc/pam.d/common-session; it has many common- things in fact, and in /etc/pam.d/sshd i for example see # # /etc/pam.d/sshd - openssh service module configuration # authinclude common-auth account include common-account passwordinclude common-password session include common-session --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: PAM module for loading ZFS keys on login
Eric McCorkle wrote in : ... >> This patch creates a new PAM module that will load a ZFS key upon a >> successful login: https://reviews.freebsd.org/D31844. It will use the >> user's auth token as the key argument to loading a ZFS encryption key on >> a user-specific ZFS data set. ... Without knowing about libzfs i personally was stunned about the simplicity of your patch, having read the upstream one. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: PAM module for loading ZFS keys on login
I looked at the upstream one too. Mine is simple because I modified libzfs to be able to take the key directly in the key location override argument. If you look at my patch, it adds a "direct" key location, which basically works like "direct:keydata", where "keydata" is your key. In the case of the PAM module, this ends up being "direct:password". It looks like they essentially pull in all the libzfs logic for preparing keys. If you notice, they go directly to lzc_load_key (that is basically a thin wrapper around the ioctl). It's worth noting that apparently they change the key to the dataset when the user changes their password. Anyway, I've seen enough. I'm going to abandon the review for my PAM module and use the upstream one. I'm going to keep the review for the autounmountd patch live, though. On 9/6/21 2:53 PM, Steffen Nurpmeso wrote: > Eric McCorkle wrote in > : > ... > >> This patch creates a new PAM module that will load a ZFS key upon a > >> successful login: https://reviews.freebsd.org/D31844. It will use the > >> user's auth token as the key argument to loading a ZFS encryption key on > >> a user-specific ZFS data set. > ... > > Without knowing about libzfs i personally was stunned about the > simplicity of your patch, having read the upstream one. > > --steffen > | > |Der Kragenbaer,The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) >
Re: PAM module for loading ZFS keys on login
Honestly, I think the best approach to this is the autounmountd unload keys thing. There's just too many ways the sessions thing can go wrong. The autounmountd solution gets the job done, and it tolerates possible failures better than anything else I can think of, barring some kind of major kernel-side awareness of sessions. There's potentially a gap between the user logging out and the keys being unloaded, but that's not much of a problem when you consider the most likely use case. The thing to keep in mind with the primary use case I've suggested for the ZFS key load/unload stuff is that it's not so much about preventing the Adversary from gaining access to data is it is about constraining when they need to be active to pull off an exfiltration. This is the real reason you see it on secure systems: it makes the Adversary's job a lot harder, while at the same time making the jobs of defensive ops and DFIR folks a whole lot easier. Say I've got sensitive files in my home directory. On a base system, the Adversary just has to circumvent OS file protections, but they can do this at any time. This means your DFIR folks have to dig through a huge amount of history. If I have to be logged in for the keys to be present, then the Adversary has to have some kind of monitoring to detect when I am, and then has a constrained window in which to pull off the attack. Both of these increase the likelihood of detection, while also constraining the window of time the DFIR folks have to examine. This isn't changed much by having the system wait some small time interval after I'm logged out to unmount my home directory and unload my keys. (If anything, it introduces another potential vector for detection: the unmounting/unloading will fail if someone is still accessing my data after I'm gone.) On 9/6/21 10:01 AM, Steffen Nurpmeso wrote: > Eric McCorkle wrote in > : > |Interesting, I wasn't aware of the upstream module. I'd say that's > > It's existence was the reason i have readded (now optional, and > a tad different) session support for my pam_xdg PAM module, > because i was thinking that, if such a many-eyes-seen thing of > a software project that claims to be and aims at being enterprise, > ships such a terrible and terribly broken thing, then i can also > offer session tracking. But my manual at least states > > CAVEATS >On Unix systems any “daemonized” program or script is reparented to the >program running with PID 1, most likely leaving the PAM user session >without PAM recognizing this. Yet careless such code may hold or > expect >availability of resources of the session it just left, truly performing >cleanup when sessions end seems thus unwise. Since so many PAM modules >do support session tracking and cleanup pam_xdg.so readded optional > sup‐ >port for this. > > But the real solution would be PAM session tracking in-kernel, > somehow, wouldn't it? > Also, on FreeBSD and OpenPAM many separate files exist in > /etc/pam.d for things which might open a session, whereas linuxpam > at least has /etc/pam.d/common-session; it has many common- things > in fact, and in /etc/pam.d/sshd i for example see > > # > # /etc/pam.d/sshd - openssh service module configuration > # > > authinclude common-auth > > account include common-account > > passwordinclude common-password > > session include common-session > > --steffen > | > |Der Kragenbaer,The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) >
Re: PAM module for loading ZFS keys on login
Interesting, I wasn't aware of the upstream module. I'd say that's preferable to the one I wrote. I think you would need to wire that into the 'modules' directory under libpam. I can look into doing that. On 9/5/21 11:27 AM, Greg wrote: > > > On September 5, 2021 4:54:26 PM GMT+03:00, Eric McCorkle > wrote: >> All, >> >> This patch creates a new PAM module that will load a ZFS key upon a >> successful login: https://reviews.freebsd.org/D31844. It will use the >> user's auth token as the key argument to loading a ZFS encryption key on >> a user-specific ZFS data set. > > There's already an upstream module which I've attached to the build in > https://reviews.freebsd.org/D28018 > > Any particular reason to write a custom one? >
Re: PAM module for loading ZFS keys on login
On September 5, 2021 4:54:26 PM GMT+03:00, Eric McCorkle wrote: >All, > >This patch creates a new PAM module that will load a ZFS key upon a >successful login: https://reviews.freebsd.org/D31844. It will use the >user's auth token as the key argument to loading a ZFS encryption key on >a user-specific ZFS data set. There's already an upstream module which I've attached to the build in https://reviews.freebsd.org/D28018 Any particular reason to write a custom one?
PAM module for loading ZFS keys on login
All, This patch creates a new PAM module that will load a ZFS key upon a successful login: https://reviews.freebsd.org/D31844. It will use the user's auth token as the key argument to loading a ZFS encryption key on a user-specific ZFS data set. This is the other side of my changeset to have autounmountd unload ZFS keys when it unloads a filesystem. (Here: https://reviews.freebsd.org/D31725) With these two changes, it should be possible to have ZFS encrypted home directories with keys dynamically loaded when users log in, and unloaded when their home directories are unmounted. Please review and comment.
Allowing local console root login on PAM initialization failure
Hello all, I have a question regarding the behavior of the PAM module, in particular pertaining to the default behavior wherein root login is completely disabled (even from the physical console) when the permissions on the PAM configuration files in `/etc/pam.d/` are incorrect (anything other than `600`). It absolutely makes sense for the PAM mechanism to fail to initialize for safety reasons under these circumstances, and activities such as remote login, ssh authentication, su/sudo, etc. all make sense to be blocked. But given that the PAM configuration can be reset from the local machine in single user mode, is there a benefit to blocking root login at the tty when PAM fails to initialize? For reference, attempting to log in at the console when the permissions on `/etc/pam.d/` are incorrect gives the following error: ``` freebsd login: in openpam_check_desc_owner_perms(): /etc/pam.d/login: insecure ownership or permissions freebsd login: pam_start(): system error ``` Just wondering if this behavior is intentional or if patches to allow login at the local console upon PAM failure would be welcomed. Thank you, Mahmoud Al-Qudsi NeoSmart Technologies ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PAM passwdqc, strict aliasing, and WARNS
On Sun, Jul 15, 2012 at 12:09:17AM +0200, Dag-Erling Smørgrav wrote: Justin T. Gibbs gi...@freebsd.org writes: Someone who has yet to confess added -Werror to the global CFLAGS (via /etc/make.conf) for one of our systems at work. Before I figured out that this was the cause of builds failing, I hacked up pam_passwdc to resolve the problem. This gets the module to WARNS=2, but to go farther, the logically const issues with this code will need to be sorted out. Is this change worth committing? Is this the best way to resolve the strict aliasing issues in this code? I really don't like that sort of game. If you look at other PAM consumer code, you'll see that the common idiom is what Jilles suggested, i.e. use a temporary variable of the appropriate type. That being said, pam_passwdqc should probably be either updated or removed. The version we have is ten years old. But it still works... pgpHVgPH4UfGi.pgp Description: PGP signature
Re: PAM passwdqc, strict aliasing, and WARNS
On Fri, Jul 13, 2012 at 04:14:17PM -0600, Justin T. Gibbs wrote: Someone who has yet to confess added -Werror to the global CFLAGS (via /etc/make.conf) for one of our systems at work. Before I figured out that this was the cause of builds failing, I hacked up pam_passwdc to resolve the problem. This gets the module to WARNS=2, but to go farther, the logically const issues with this code will need to be sorted out. Is this change worth committing? Is this the best way to resolve the strict aliasing issues in this code? The prototype of pam_get_item() is int pam_get_item(const pam_handle_t *pamh, int item_type, const void **item); Therefore, you should pass a pointer to a const void pointer as the last argument. You can then convert the const void pointer to the desired type. For example: const void *item; const struct pam_conv *conv; result = pam_get_item(pamh, PAM_CONV, item); conv = item; Passing something like a pointer to a 'const struct pam_conv *' to pam_get_item() will cause a strict-aliasing violation because pam_get_item() will attempt to store a value into an object of declared type 'const struct pam_conv *' using an lvalue of type 'const void *'. In both C99 and C11, these rules are in 6.5 Expressions. In the case of const struct pam_conv *, the union approach violates the C standard because the C standard does not guarantee that all object pointers have the same representation. The conversion might be non-trivial and a type-pun may not work properly. However, in almost all real machines the conversion is trivial. Some compilers may still consider the union approach a strict-aliasing violation. In any case, I think it is a bit ugly and should be avoided when possible (like here). -- Jilles Tjoelker ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: PAM passwdqc, strict aliasing, and WARNS
Justin T. Gibbs gi...@freebsd.org writes: Someone who has yet to confess added -Werror to the global CFLAGS (via /etc/make.conf) for one of our systems at work. Before I figured out that this was the cause of builds failing, I hacked up pam_passwdc to resolve the problem. This gets the module to WARNS=2, but to go farther, the logically const issues with this code will need to be sorted out. Is this change worth committing? Is this the best way to resolve the strict aliasing issues in this code? I really don't like that sort of game. If you look at other PAM consumer code, you'll see that the common idiom is what Jilles suggested, i.e. use a temporary variable of the appropriate type. That being said, pam_passwdqc should probably be either updated or removed. The version we have is ten years old. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
PAM passwdqc, strict aliasing, and WARNS
Someone who has yet to confess added -Werror to the global CFLAGS (via /etc/make.conf) for one of our systems at work. Before I figured out that this was the cause of builds failing, I hacked up pam_passwdc to resolve the problem. This gets the module to WARNS=2, but to go farther, the logically const issues with this code will need to be sorted out. Is this change worth committing? Is this the best way to resolve the strict aliasing issues in this code? Thanks, Justin pam_passwdqc.diff Description: Binary data ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Latest PAM seems to break su
su Segmentation fault: 11 no core is produced. Currently broken: r236118 Previous r235567 sudo works. -- This .signature sanitized for your protection ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Latest PAM seems to break su
Doug Barton do...@freebsd.org writes: su Segmentation fault: 11 Weird, I've been running it for months... I'll look into it right away. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: couldn't log on to my -CURRENT machine after upgrade to latest PAM
Don Lewis truck...@freebsd.org writes: building shared library libpam.so.5 make: don't know how to make openpam.3. Stop *** Error code 2 Ah, yes, the man pages are generated during the release process, so you either have to copy them over from the original contrib/openpam directory (or export the new sources on top of the existing directory) or build with -DNO_MAN. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: couldn't log on to my -CURRENT machine after upgrade to latest PAM
On 11 Jan, Dag-Erling Smørgrav wrote: Could you please try this: # cd /usr/src/contrib # mv openpam openpam.orig # svn export svn://svn.des.no/openpam/trunk@526 openpam # cd ../lib/libpam # make depend make all make install [snip] building shared library libpam.so.5 make: don't know how to make openpam.3. Stop *** Error code 2 Other than that, it works great and doesn't get tripped up by my obsolete /etc/pam.conf. Thanks! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: couldn't log on to my -CURRENT machine after upgrade to latest PAM
If at any point in this conversation I seemed to make _no sense at all_, it was because I conflated it with a completely different OpenPAM issue (error reporting in openpam_dynamic.c) which has been on my mind lately. Sorry about that. I will attempt to address both issues in the next release, which I intend to roll in February. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: couldn't log on to my -CURRENT machine after upgrade to latest PAM
On 10 Jan, Dag-Erling Smørgrav wrote: If at any point in this conversation I seemed to make _no sense at all_, it was because I conflated it with a completely different OpenPAM issue (error reporting in openpam_dynamic.c) which has been on my mind lately. Sorry about that. I will attempt to address both issues in the next release, which I intend to roll in February. Yeah, I didn't see where the change in question would affect error handling, but I think my first patch suggestion would ignore errors. I thought you were commenting on that in your followup messsage. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: couldn't log on to my -CURRENT machine after upgrade to latest PAM
Could you please try this: # cd /usr/src/contrib # mv openpam openpam.orig # svn export svn://svn.des.no/openpam/trunk@526 openpam # cd ../lib/libpam # make depend make all make install In addition to the pam.conf issue, the major changes relative to head are reduced log spam, improved log messages in certain error conditions, and a different default password prompt for remote logins. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: couldn't log on to my -CURRENT machine after upgrade to latest PAM
Don Lewis truck...@freebsd.org writes: The documentation says that /etc/pam.conf is only used if /etc/pam.d/service-name isn't found, and the code appears to agree with that, however this doesn't seem to be working as expected after the latest import of PAM. The culprit was this commit: http://trac.des.no/openpam/changeset/487/trunk/lib/openpam_configure.c However, I'm not confident that simply reverting this commit is the right way to go. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: couldn't log on to my -CURRENT machine after upgrade to latest PAM
On 9 Jan, Dag-Erling Smørgrav wrote: Don Lewis truck...@freebsd.org writes: The documentation says that /etc/pam.conf is only used if /etc/pam.d/service-name isn't found, and the code appears to agree with that, however this doesn't seem to be working as expected after the latest import of PAM. The culprit was this commit: http://trac.des.no/openpam/changeset/487/trunk/lib/openpam_configure.c However, I'm not confident that simply reverting this commit is the right way to go. Thanks for the detective work. It looks to me like the bug is caused by the change in the openpam_parse_chain() return value. In the previous code it returned the value of count, which I would guess was greater than zero if it found something. In that case, the for loop in openpam_load_chain() would be terminated because r != 0. In the new code, openpam_parse_chain() will return PAM_SUCCESS if it found something, and the loop in openpam_load_chain() will go through another iteration because ret == PAM_SUCCESS. I think the code around the end of the loop should look more like: if (ret == PAM_SUCCESS) break; } return (ret); } ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: couldn't log on to my -CURRENT machine after upgrade to latest PAM
Don Lewis truck...@freebsd.org writes: Dag-Erling Smørgrav d...@des.no writes: The culprit was this commit: http://trac.des.no/openpam/changeset/487/trunk/lib/openpam_configure.c However, I'm not confident that simply reverting this commit is the right way to go. Thanks for the detective work. It looks to me like the bug is caused by the change in the openpam_parse_chain() return value. In the previous code it returned the value of count, which I would guess was greater than zero if it found something. In that case, the for loop in openpam_load_chain() would be terminated because r != 0. In the new code, openpam_parse_chain() will return PAM_SUCCESS if it found something, and the loop in openpam_load_chain() will go through another iteration because ret == PAM_SUCCESS. Thank you, Captain Obvious. I am still not confident that simply reverting this commit is the right way to go, because it discards valuable information when an error occurs, especially if an error occurs while parsing an include. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: couldn't log on to my -CURRENT machine after upgrade to latest PAM
On 9 Jan, Dag-Erling Smørgrav wrote: Don Lewis truck...@freebsd.org writes: Dag-Erling Smørgrav d...@des.no writes: The culprit was this commit: http://trac.des.no/openpam/changeset/487/trunk/lib/openpam_configure.c However, I'm not confident that simply reverting this commit is the right way to go. Thanks for the detective work. It looks to me like the bug is caused by the change in the openpam_parse_chain() return value. In the previous code it returned the value of count, which I would guess was greater than zero if it found something. In that case, the for loop in openpam_load_chain() would be terminated because r != 0. In the new code, openpam_parse_chain() will return PAM_SUCCESS if it found something, and the loop in openpam_load_chain() will go through another iteration because ret == PAM_SUCCESS. Thank you, Captain Obvious. I am still not confident that simply reverting this commit is the right way to go, because it discards valuable information when an error occurs, especially if an error occurs while parsing an include. It wasn't so obvious to me, especially with the gratuitous variable renaming in the diff. After staring at the code a lot more, I see your point about the loss of information. The problem is that openpam_parse_chain() returns PAM_SUCCESS whether or not if found anything, but we want the loop to terminate when either an error is detected or if openpam_parse_chain() actually found something. Maybe changing the loop exit to something like this would work: if (ret != PAM_SUCCESS || pamh-chains[facility] != NULL) return (ret); ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: couldn't log on to my -CURRENT machine after upgrade to latest PAM
Don Lewis truck...@freebsd.org writes: After staring at the code a lot more, I see your point about the loss of information. The problem is that openpam_parse_chain() returns PAM_SUCCESS whether or not if found anything, but we want the loop to terminate when either an error is detected or if openpam_parse_chain() actually found something. Maybe changing the loop exit to something like this would work: if (ret != PAM_SUCCESS || pamh-chains[facility] != NULL) return (ret); The simplest fix for now is probably to revert r487; it applies cleanly except for the first hunk, which is easy to apply manually. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: couldn't log on to my -CURRENT machine after upgrade to latest PAM
On 9 Jan, Dag-Erling Smørgrav wrote: Don Lewis truck...@freebsd.org writes: After staring at the code a lot more, I see your point about the loss of information. The problem is that openpam_parse_chain() returns PAM_SUCCESS whether or not if found anything, but we want the loop to terminate when either an error is detected or if openpam_parse_chain() actually found something. Maybe changing the loop exit to something like this would work: if (ret != PAM_SUCCESS || pamh-chains[facility] != NULL) return (ret); The simplest fix for now is probably to revert r487; it applies cleanly except for the first hunk, which is easy to apply manually. openpam_configure() checks whether or not pamh-chains[] is NULL, so I figured that was a good test once I figured out how openpam_parse_chain() was returning its results. Once you decide on a fix, I can move my old /etc/pam.conf back to test it. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
couldn't log on to my -CURRENT machine after upgrade to latest PAM
I just upgraded my -CURRENT machine for the first time since mid-November. When I rebooted, I was surprised that I was unable to log in via either ssh or directly on the console. The diagnostics printed to the console indicated that pam_skey.so was missing. Since that was nuked a long time ago, I was puzzled about why it seemed to be required again. I was able to get on the machine by booting it single user. I moved /etc/pam.conf out of the way and am now able to log in. Nothing referenced pam_skey under /etc/pam.d, but I found than I had an ancient copy of /etc/pam.conf that still used pam_skey. The documentation says that /etc/pam.conf is only used if /etc/pam.d/service-name isn't found, and the code appears to agree with that, however this doesn't seem to be working as expected after the latest import of PAM. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
pam problems
Whatever was just changed in the libpam family, it breaks courier-authdaemond: authdaemond: in openpam_load_module(): no pam_unix.so found imb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: PAM/setloginclass link error in jail
Just for the archives, this turned out to be a problem with updating the ezjail basejail directory. I had run ezjail-admin update -i, but for some reason it did not install the new libc.so.7 while it did install pretty much everything else. Moving the old basejail out of the way and installing a new basejail from scratch solved the problem. Its not clear why ezjail's cpio command failed to update the libc.so.7 file in the first place. Sorry for the noise. - Ben On Sep 5, 2011, at 7:17 PM, Ben Kelly wrote: Hello all, I upgraded my server today to a recent HEAD from its old sources from about October 2010. After the upgrade I ran into an unusual problem. I've worked around the issue for now, but I was wondering if anyone could help me solve it correctly. The problem is that all PAM related operations fail inside jails. Initially I was getting this error in /var/log/messages: passwd: in openpam_load_module(): no pam_unix.so found That file was clearly there, however, so I dug into PAM and enabled some debug in pam_dynamic.c. This got me the following message: openpam_dynamic(): /usr/lib/pam_unix.so: /lib/libutil.so.9: Undefined symbol setloginclass This is a syscall added to the system in March, 2011. The link process works fine normally, but fails in any jail. I went as far as turning on rtld debug to verify it was giving up on libutil about half way through when it could not resolve the symbol. I verified that libc.so.7 was the same both inside and outside the jail. The setloginclass symbol was defined as a WEAK reference. Looking through past e-mail I noticed trasz@ said he was going to explicitly put in code to support setloginclass from root in a jail. I think I see this code in the prison privilege checking as well. Its just not clear to me why its not linking. To work around the issue I hacked setloginclass out of libutil for now. This is clearly not ideal as I'm not sure when and where that will blow up on me. It did let me log back into my e-mail, however. For reference: FreeBSD ianto.in.wanderview.com 9.0-BETA2 FreeBSD 9.0-BETA2 #1 r278M: Mon Sep 5 18:54:58 UTC 2011 r...@ianto.in.wanderview.com:/usr/obj/usr/src/sys/SERVER i386 The system is using zfs, nullfs, and ezjail to manage the jails. I did upgrade my zfs pools to the latest version at this same time, but so far I can't tie that to this problem. Does anyone know why a jail would prevent rtld from linking in a particular syscall? Any help or advice is greatly appreciated. Thank you. Ben ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
PAM/setloginclass link error in jail
Hello all, I upgraded my server today to a recent HEAD from its old sources from about October 2010. After the upgrade I ran into an unusual problem. I've worked around the issue for now, but I was wondering if anyone could help me solve it correctly. The problem is that all PAM related operations fail inside jails. Initially I was getting this error in /var/log/messages: passwd: in openpam_load_module(): no pam_unix.so found That file was clearly there, however, so I dug into PAM and enabled some debug in pam_dynamic.c. This got me the following message: openpam_dynamic(): /usr/lib/pam_unix.so: /lib/libutil.so.9: Undefined symbol setloginclass This is a syscall added to the system in March, 2011. The link process works fine normally, but fails in any jail. I went as far as turning on rtld debug to verify it was giving up on libutil about half way through when it could not resolve the symbol. I verified that libc.so.7 was the same both inside and outside the jail. The setloginclass symbol was defined as a WEAK reference. Looking through past e-mail I noticed trasz@ said he was going to explicitly put in code to support setloginclass from root in a jail. I think I see this code in the prison privilege checking as well. Its just not clear to me why its not linking. To work around the issue I hacked setloginclass out of libutil for now. This is clearly not ideal as I'm not sure when and where that will blow up on me. It did let me log back into my e-mail, however. For reference: FreeBSD ianto.in.wanderview.com 9.0-BETA2 FreeBSD 9.0-BETA2 #1 r278M: Mon Sep 5 18:54:58 UTC 2011 r...@ianto.in.wanderview.com:/usr/obj/usr/src/sys/SERVER i386 The system is using zfs, nullfs, and ezjail to manage the jails. I did upgrade my zfs pools to the latest version at this same time, but so far I can't tie that to this problem. Does anyone know why a jail would prevent rtld from linking in a particular syscall? Any help or advice is greatly appreciated. Thank you. Ben___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: NSS and PAM, dynamic vs. static
On Sat, Nov 29, 2003 at 02:01:02PM +0100, Matthias Andree wrote: Jacques A. Vidrine [EMAIL PROTECTED] writes: NSS and PAM do not overlap. I wonder how PAM gets system authentication information for pam_pwdb or pam_unix or how it's called today and on the pertinent system if not through NSS. Reimplementation of these passwd/shadow/whatever mechanisms? No, PAM uses the system directory services APIs (e.g. getpwnam(3) and similar). Those in turn use NSS, on NSS systems. Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM
On Sat, Nov 29, 2003 at 02:45:24AM +0100, Dag-Erling Smørgrav wrote: Jacques A. Vidrine [EMAIL PROTECTED] writes: Interesting. Explain, please. (Maybe privately or in another thread; hate to keep this'n going.) Perhaps you mean that it is a design flaw that two APIs are required. If so, I happen to disagree; I think that the separation of directory services and authentication is appropriate and necessary. No, the two are essentially one. We just think they aren't because we've been brainwashed to think of users in terms of uids and gids and especially struct passwd, which deserves to die. By `the two', do you mean directory services and authentication? They are certainly not `essentially one'. But I suspect you know this and I am just misunderstanding your meaning. NSS itself doesn't make much sense to me; it's an elaborate hack designed to drag all those nice shiny directory services down in the mud where struct passwd has been wallowing for the past twenty years, instead of allowing applications to take advantage of their superior functionality. I guess I think of it this way. If NSS had not been implemented `down in the mud' (inside getpw*, getgr*, gethostby*, etc.), then applications that used the UNIX directory service APIs would need to be re-written in order to utilize NSS. That's a lot of code to change for little benefit. PAM is different. Applications *had* to be re-written to utilize PAM, because previously there was no real authentication API, just crypt() and strcmp()--- obviously insufficient for many authentication methods :-) As for PAM, a lot of what's wrong with it today could be fixed by redesigning it to include directory services. If you fixed the conversation system (by formalizing service function execution as an FSM) and cleaned up the configuration syntax, you'd end up with something quite nice. If I understand you correctly, you believe that it would be possible to unite the NSS and PAM switches, so that they used the same configuration file, dynamic loading mechanisms, cascading, and so on. Sure, I think that's possible. There might even be some benefit, though probably not enough benefit to abandon PAM/NSS and go our own way. Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM
Jacques A. Vidrine [EMAIL PROTECTED] writes: By `the two', do you mean directory services and authentication? They are certainly not `essentially one'. But I suspect you know this and I am just misunderstanding your meaning. They are different issues, but in this context you can't discuss one without the other. Authentication doesn't work unless you have a user to authenticate. It makes no sense to separate them; you just end up duplicating a lot of concepts and code. Also, is changing your password an authentication function or a directory function? I don't think you can answer either without answering both. I guess I think of it this way. If NSS had not been implemented `down in the mud' (inside getpw*, getgr*, gethostby*, etc.), then applications that used the UNIX directory service APIs would need to be re-written in order to utilize NSS. That's a lot of code to change for little benefit. Backward compatibility is fine, but NSS does not seem to export an API that we can use when we want to lift ourselves out of the mud, so we are forced to keep rooting around in it. One consequence of this (and of the artificial separation between NSS and PAM) is that passwd(1) doesn't work properly except in the simplest cases. If I understand you correctly, you believe that it would be possible to unite the NSS and PAM switches, so that they used the same configuration file, dynamic loading mechanisms, cascading, and so on. Sure, I think that's possible. There might even be some benefit, though probably not enough benefit to abandon PAM/NSS and go our own way. Not to go our own way, no. There's the rub. It would have to be a reasonably wide effort; we'd need to get at least one major Linux distro to adopt the same infrastructure. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM
On Mon, 1 Dec 2003, Dag-Erling Smørgrav wrote: Jacques A. Vidrine [EMAIL PROTECTED] writes: By `the two', do you mean directory services and authentication? They are certainly not `essentially one'. But I suspect you know this and I am just misunderstanding your meaning. They are different issues, but in this context you can't discuss one without the other. Authentication doesn't work unless you have a user to authenticate. It makes no sense to separate them; you just end up duplicating a lot of concepts and code. Also, is changing your password an authentication function or a directory function? I don't think you can answer either without answering both. It strikes me that there are two separate issues: (1) Whether or not there's a useful distinction between authentication services and directory services. (2) If there is or isn't such a distinction in (1), whether or not that distinction should appear in the implementation. In practice, people frequently mix and match authentication services and directory services, and there are services that implement one but not the other. For example, Kerberos5 for authentication an LDAP for directory services is a common combination: however, Kerberos doesn't provide directory services, only principal authentication. Likewise, even on purely local systems, the account directory services (pwent, et al) may be distinct from principal authentication using one-time passwords, etc. I'm not opposed to the fundamental idea of combining mechanism, but there are some practical underlying differences between directory services and authentication, even though there's clear overlap. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Senior Research Scientist, McAfee Research ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM
On Mon, 2003-12-01 at 11:48, Dag-Erling Smrgrav wrote: If I understand you correctly, you believe that it would be possible to unite the NSS and PAM switches, so that they used the same configuration file, dynamic loading mechanisms, cascading, and so on. Sure, I think that's possible. There might even be some benefit, though probably not enough benefit to abandon PAM/NSS and go our own way. Not to go our own way, no. There's the rub. It would have to be a reasonably wide effort; we'd need to get at least one major Linux distro to adopt the same infrastructure. Has anyone considered the idea of hybridizing PAM with Digital^WCompaq^WHP's SIA matrix setup? -- brandon s. allbery[linux,solaris,freebsd,perl] [EMAIL PROTECTED] system administrator [WAY too many hats][EMAIL PROTECTED] electrical and computer engineering, carnegie mellon univ. KF8NH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM
On Mon, Dec 01, 2003 at 05:48:22PM +0100, Dag-Erling Smørgrav wrote: They are different issues, but in this context you can't discuss one without the other. Authentication doesn't work unless you have a user to authenticate. It makes no sense to separate them; you just end up duplicating a lot of concepts and code. Hmm, I disagree completely. :-) They can be separated and should be separated. Systems that mix them up are flawed. The confusion of the two are what *causes* the problem you bring up below (passwd(1)). Authentication simply names you. It is quite possible to be authenticated in some context and have absolutely no privileges or other information (``in a vacuum'', if you will). It is even useful in some cases: = `Junk' certificates = `Junk' Kerberos principals = A disabled account = A newly-created account More practically speaking, the mechanism by which you authenticate usually has no bearing on what you are authorized to do. This is the power of properly separating authentication and authorization: regardless of whether I authenticate by entering my password, inserting my smart card and PIN, or supplying a Kerberos ticket, my privileges will be the same [1]. Similarly, if the IT department moved from NIS to LDAP over the weekend, all my existing authentication tokens naturally still work. That's not to say that you *cannot* combine authentication and authorization, but they are naturally independent and different protocols and semantics are required for one and the other. RADIUS is a good example. It is quite difficult to properly support a variety of authentication mechanisms in RADIUS. Diameter addresses the issue by supporting a separate authentication protocol, EAP, which in turn allows for various authentication mechanisms generically. Also, is changing your password an authentication function or a directory function? I don't think you can answer either without answering both. I think it is strictly an authentication function. The change in your password has no affect on your UID, or your phone number, or in what ACLs your name appears in. I guess I think of it this way. If NSS had not been implemented `down in the mud' (inside getpw*, getgr*, gethostby*, etc.), then applications that used the UNIX directory service APIs would need to be re-written in order to utilize NSS. That's a lot of code to change for little benefit. Backward compatibility is fine, but NSS does not seem to export an API that we can use when we want to lift ourselves out of the mud, so we are forced to keep rooting around in it. What's an example of what you mean? The BSD nsswitch implementation has a generic nsdispatch(3) that allows for new applications, but I'm not sure that is what you mean. At any rate, it is not `NSS' proper, it is an implementation detail. One consequence of this (and of the artificial separation between NSS and PAM) is that passwd(1) doesn't work properly except in the simplest cases. It seems to me that this is a direct result of passwd(1) confusing authentication and authorization. Other than determining the default target user name from the current UID, passwd(1) needs only to invoke PAM interfaces to change your password for any authentication method that supports password changing. Of course this won't work for certain legacy, read-mostly `authentication methods' such as NIS or Hesiod that aren't supported by PAM. If I understand you correctly, you believe that it would be possible to unite the NSS and PAM switches, so that they used the same configuration file, dynamic loading mechanisms, cascading, and so on. Sure, I think that's possible. There might even be some benefit, though probably not enough benefit to abandon PAM/NSS and go our own way. Not to go our own way, no. There's the rub. It would have to be a reasonably wide effort; we'd need to get at least one major Linux distro to adopt the same infrastructure. Indeed, ``there's the rub'' :-) Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [1] Mostly. An application might require that you used a strong authentication method, to launch the nukes or something. :-) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM
Jacques A. Vidrine [EMAIL PROTECTED] writes: Hmm, I disagree completely. :-) [...] You are bringing authorization into the fray... we're talking about directory services (retrieving information about a user) and authentication (identifying someone as that user), not authorization. Also, is changing your password an authentication function or a directory function? I don't think you can answer either without answering both. I think it is strictly an authentication function. The change in your password has no affect on your UID, or your phone number, or in what ACLs your name appears in. The problem is that the authentication information needs to be stored somewhere, and the usual solution is to store it in the directory, so changing the password involves both authentication and directory services. Backward compatibility is fine, but NSS does not seem to export an API that we can use when we want to lift ourselves out of the mud, so we are forced to keep rooting around in it. What's an example of what you mean? The BSD nsswitch implementation has a generic nsdispatch(3) that allows for new applications, but I'm not sure that is what you mean. At any rate, it is not `NSS' proper, it is an implementation detail. Like you say, it is an implementation detail, and it is far too low-level to be of use. We need an API that retrieves information about a user according to rules established by the administrator (nsswitch.conf or pam.conf or whatever) and is flexible enough to handle the fact that different directories store different amounts of information about the users at different levels of detail (for instance, LDAP stores first and last name separately while /etc/passwd only has the one GCOS field). It seems to me that this is a direct result of passwd(1) confusing authentication and authorization. Other than determining the default target user name from the current UID, passwd(1) needs only to invoke PAM interfaces to change your password for any authentication method that supports password changing. No, because PAM doesn't control retrieval of the user information. If it did, it would be as simple as you say, but it doesn't - NSS does - so it's a nightmare. Imagine the case where different directories contain different entries for the same user, or for different users who happen to have the same name; this is standard practice with NIS. Which directory do you write the modified entry into? The obvious answer is the one it came out of in the first place, but PAM doesn't know which one that was. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM
On Mon, 01 Dec 2003 23:24:40 +0100, [EMAIL PROTECTED] (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) said: The problem is that the authentication information needs to be stored somewhere, and the usual solution is to store it in the directory, ...which is usually the worst possible place. Please don't penalize those of us with sensible authentication systems. -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM
Garrett Wollman [EMAIL PROTECTED] writes: On Mon, 01 Dec 2003 23:24:40 +0100, [EMAIL PROTECTED] (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) said: The problem is that the authentication information needs to be stored somewhere, and the usual solution is to store it in the directory, ...which is usually the worst possible place. Please don't penalize those of us with sensible authentication systems. You're the one trying to penalize other people. A common framework for directory and authentication services can of course store authentication tokens separately from user information, but the reverse isn't true. You can't unilaterally decide to leave out functionality that 90% of our users require just because you are in a position to use (what you consider to be) a better solution. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM
Garrett Wollman wrote: On Mon, 01 Dec 2003 23:24:40 +0100, [EMAIL PROTECTED] (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) said: The problem is that the authentication information needs to be stored somewhere, and the usual solution is to store it in the directory, ...which is usually the worst possible place. Please don't penalize those of us with sensible authentication systems. Care to elaborate, Garrett? I've been following this discussion with some interest, and would like to see people elucidate their positions and concerns. Both DES and Jacques have made some interesting points so far. What exactly is your sensible authentication system? Why is the directory usually the worst for storing authentication information? What do you think are the correct fracture points and how do they relate to the existing PAM/NSS frameworks? Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM
On Mon, 2003-12-01 at 21:24, Tim Kientzle wrote: Why is the directory usually the worst for storing authentication information? This one's fairly easy to answer: you want to stick authentication data into a potentially public/exposed directory? Even traditional Unix uses /etc/shadow (or more complex solutions on some commercial systems) these days, so the password isn't in the directory (/etc/passwd). However, I have to agree with des's argument: a combined matrix for directory and authentication services doesn't mean the *data* must be combined. Using (for example) SIA, one could specify Kerberos 5 (my guess as to wollman's better answer) and LDAP, and simply not specify entry points for the parts that each doesn't handle (Kerberos doesn't support directory services, and LDAP isn't being used for authentication), with later entries falling back to NIS or traditional files. But this arrangement allows traditional APIs to work reasonably --- and you can layer PAM and NSS on top of it as compatibility APIs. -- brandon s. allbery[linux,solaris,freebsd,perl] [EMAIL PROTECTED] system administrator [WAY too many hats][EMAIL PROTECTED] electrical and computer engineering, carnegie mellon univ. KF8NH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM (was Re: NSS and PAM, dynamic vs. static)
why does /bin/sh need NSS support? Jacques A. Vidrine wrote: [Threading intentionally broken.] On Sat, Nov 29, 2003 at 01:16:25AM +0100, Dag-Erling Sm?rgrav wrote: Jacques A. Vidrine [EMAIL PROTECTED] writes: NSS and PAM do not overlap. They are complimentary and one cannot do the job of the other. That is a bug in NSS, PAM or both. Interesting. Explain, please. (Maybe privately or in another thread; hate to keep this'n going.) Perhaps you mean that it is a design flaw that two APIs are required. If so, I happen to disagree; I think that the separation of directory services and authentication is appropriate and necessary. (BTW, I think you mean that they are complementary, not complimentary, although it is certainly true that some implementations of NSS and PAM are free) heh, Yes, that's a spell-o from which spell-check could not save me. Cheers, -- --- I'm a UNIX Kinda Guy. My websites: http://slavepix.dyns.net/ http://jaxleather.dyns.net/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM, dynamic vs. static
Jacques A. Vidrine [EMAIL PROTECTED] writes: On Wed, Nov 26, 2003 at 02:00:08AM +0100, Matthias Andree wrote: Matthew Dillon [EMAIL PROTECTED] writes: How much do you intend to use NSS for? I mean, what's the point of adopting this cool infrastructure if all you are going to do with it is make a better PAM out of it? The important thing is that NSS allows to plug modules such as LDAP or PostgreSQL for user base management. PAM is only halfway there and doesn't give libc et al. a notion of a user or group context (in spite of its account context), NSS does. One might discuss if PAM is really needed with NSS in place, but it's hard to think of a system without NSS and removing PAM now doesn't look right. NSS and PAM do not overlap. I wonder how PAM gets system authentication information for pam_pwdb or pam_unix or how it's called today and on the pertinent system if not through NSS. Reimplementation of these passwd/shadow/whatever mechanisms? -- Matthias Andree Encrypt your mail: my GnuPG key ID is 0x052E7D95 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM
Richard Coleman [EMAIL PROTECTED] writes: Replacing passwd/group/NSS/PAM/whatever with a real database or directory backend is a kind of holy grail for Unix that's been discussed for many years. You're mixing apples and oranges here. NSS and PAM are not backends in themselves; they are frameworks that allow the admin to select and combine directory and authentication backends and policies. You can't get by without them, because you will never find a single solution that can replace the entire installed base of LDAP, Radius, TAC+, Kerberos etc., and you can't enforce policy from the backend. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM (was Re: NSS and PAM, dynamic vs. static)
slave-mike [EMAIL PROTECTED] writes: why does /bin/sh need NSS support? Because /bin/sh uses getpwnam(). We've been through this before. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM (was Re: NSS and PAM, dynamic vs. static)
slave-mike wrote: why does /bin/sh need NSS support? 1. If you are using pam_ldap, tilde expansion will be broken in /bin/sh without nss_ldap support. 2. Tilde expansion is required for POSIX conformance. It's not the strongest rationale. But it's something to consider. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM, dynamic vs. static
Jacques A. Vidrine [EMAIL PROTECTED] writes: NSS and PAM do not overlap. They are complimentary and one cannot do the job of the other. That is a bug in NSS, PAM or both. (BTW, I think you mean that they are complementary, not complimentary, although it is certainly true that some implementations of NSS and PAM are free) DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
NSS and PAM (was Re: NSS and PAM, dynamic vs. static)
[Threading intentionally broken.] On Sat, Nov 29, 2003 at 01:16:25AM +0100, Dag-Erling Smørgrav wrote: Jacques A. Vidrine [EMAIL PROTECTED] writes: NSS and PAM do not overlap. They are complimentary and one cannot do the job of the other. That is a bug in NSS, PAM or both. Interesting. Explain, please. (Maybe privately or in another thread; hate to keep this'n going.) Perhaps you mean that it is a design flaw that two APIs are required. If so, I happen to disagree; I think that the separation of directory services and authentication is appropriate and necessary. (BTW, I think you mean that they are complementary, not complimentary, although it is certainly true that some implementations of NSS and PAM are free) heh, Yes, that's a spell-o from which spell-check could not save me. Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM
Jacques A. Vidrine [EMAIL PROTECTED] writes: Interesting. Explain, please. (Maybe privately or in another thread; hate to keep this'n going.) Perhaps you mean that it is a design flaw that two APIs are required. If so, I happen to disagree; I think that the separation of directory services and authentication is appropriate and necessary. No, the two are essentially one. We just think they aren't because we've been brainwashed to think of users in terms of uids and gids and especially struct passwd, which deserves to die. NSS itself doesn't make much sense to me; it's an elaborate hack designed to drag all those nice shiny directory services down in the mud where struct passwd has been wallowing for the past twenty years, instead of allowing applications to take advantage of their superior functionality. As for PAM, a lot of what's wrong with it today could be fixed by redesigning it to include directory services. If you fixed the conversation system (by formalizing service function execution as an FSM) and cleaned up the configuration syntax, you'd end up with something quite nice. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM
Dag-Erling Smørgrav wrote: NSS itself doesn't make much sense to me; it's an elaborate hack designed to drag all those nice shiny directory services down in the mud where struct passwd has been wallowing for the past twenty years, instead of allowing applications to take advantage of their superior functionality. As for PAM, a lot of what's wrong with it today could be fixed by redesigning it to include directory services. If you fixed the conversation system (by formalizing service function execution as an FSM) and cleaned up the configuration syntax, you'd end up with something quite nice. DES Replacing passwd/group/NSS/PAM/whatever with a real database or directory backend is a kind of holy grail for Unix that's been discussed for many years. I would love to see it happen. But I doubt it could ever happen within a collaborative project like FreeBSD, since it would be impossible to get enough people to agree upon the innumerable small details. I don't want to sound so pessimistic, but I think that's just a reality of group projects. I think this is part of the reason that many people are passionate about the dynamic library implementation of PAM/NSS. We realize that the odds are very high that the alternatives will be endlessly discussed, but never implemented. Since this is a feature that many of us really need, we prefer the less than perfect but existing implementation to the perfect, but never implemented solution. This discussion has really reminded me of the classic paper by Richard Gabriel on Lisp: Good News, Bad News, How to Win Big. This is one of the best essays on the Worse is Better phenomenon. http://www.ai.mit.edu/docs/articles/good-news/good-news.html http://www.dreamsongs.com/WorseIsBetter.html Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM, dynamic vs. static (was: 40% slowdown with dynamic /bin/sh)
On Wed, Nov 26, 2003 at 02:00:08AM +0100, Matthias Andree wrote: Matthew Dillon [EMAIL PROTECTED] writes: How much do you intend to use NSS for? I mean, what's the point of adopting this cool infrastructure if all you are going to do with it is make a better PAM out of it? The important thing is that NSS allows to plug modules such as LDAP or PostgreSQL for user base management. PAM is only halfway there and doesn't give libc et al. a notion of a user or group context (in spite of its account context), NSS does. One might discuss if PAM is really needed with NSS in place, but it's hard to think of a system without NSS and removing PAM now doesn't look right. NSS and PAM do not overlap. They are complimentary and one cannot do the job of the other. Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
NSS and PAM, dynamic vs. static (was: 40% slowdown with dynamic /bin/sh)
Matthew Dillon [EMAIL PROTECTED] writes: How much do you intend to use NSS for? I mean, what's the point of adopting this cool infrastructure if all you are going to do with it is make a better PAM out of it? The important thing is that NSS allows to plug modules such as LDAP or PostgreSQL for user base management. PAM is only halfway there and doesn't give libc et al. a notion of a user or group context (in spite of its account context), NSS does. One might discuss if PAM is really needed with NSS in place, but it's hard to think of a system without NSS and removing PAM now doesn't look right. Of course, you can stuff the whole NSS client side (thinking IPC) into a statically linked executable. To stall this discussion: I don't mind if NSS is dynamically or statically linked. I won't let this drift into any other dynamic - static discussion. reason that I can see, and coming up with all sorts of extra junk, like /rescue, to work around that fact. As a user, I like /rescue better than the step-child that /stand/* used to be. It's part of the world, which /stand wasn't. One word of warning: there used to be SuSE Linux versions that wouldn't let you log in single-user mode when the system was using NIS in multi-user because there was nothing to communicate with through AF_UNIX sockets yet this was expected to be able to log in. There are potholes and pitfalls that I consider major considered with a dynamic /bin /sbin setup. Watch out. -- Matthias Andree Encrypt your mail: my GnuPG key ID is 0x052E7D95 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM, dynamic vs. static (was: 40% slowdown with dynamic /bin/sh)
On Wed, Nov 26, 2003 at 02:00:08AM +0100, Matthias Andree wrote: As a user, I like /rescue better than the step-child that /stand/* used to be. It's part of the world, which /stand wasn't. Except that we still have /stand. It should be shot, but some won't let it go... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM, dynamic vs. static (was: 40% slowdown with dynamic /bin/sh)
On Tue, 25 Nov 2003, David O'Brien wrote: On Wed, Nov 26, 2003 at 02:00:08AM +0100, Matthias Andree wrote: As a user, I like /rescue better than the step-child that /stand/* used to be. It's part of the world, which /stand wasn't. Except that we still have /stand. It should be shot, but some won't let it go... We have it, it's buggy (I didn't bother to report it tried to create a 5th primary partition and shot all my extended partitions in turn yet) and unbeloved -- but it doesn't get built when you type make buildworld, which is what my phrase was about. Sorry if I was unclear. Maybe FreeBSD should just use Linux' fdisk which works fine and would need only minor BSD label polishing, if any. License permitting (-: -- Matthias Andree Encrypt your mail: my GnuPG key ID is 0x052E7D95 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
PAM, X11, and su as a normal user? (fwd)
I sent this inquire to freebsd-question, but came up empty with respect to solutions to the problem. I have 2 accounts on my freebsd-current machine. I use startx to start X11 as user kargl. If I then su to user sgk, I cannot fire up X clients. For example, troutmask:kargl[202] su sgk Password: troutmask:sgk[201] gnuplot Terminal type set to 'x11' gnuplot plot sin(x) gnuplot gnuplot: unable to open display 'troutmask.apl.washington.edu:0' gnuplot: X11 aborted. I've tried using xhost sgk@, but this doesn't work. I have also used xauth to ensore that both user kargl and user sgk have the same key in .Xauthority. The only thing I can think of that may need to be configured is PAM, but the documentation is rather incomplete. So, anyone know how to setup su to permit sgk to use X clients? -- Steve http://troutmask.apl.washington.edu/~kargl/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PAM, X11, and su as a normal user? (fwd)
On Sat, 2003-09-06 at 02:13, Steven G. Kargl wrote: I have 2 accounts on my freebsd-current machine. I use startx to start X11 as user kargl. If I then su to user sgk, I cannot fire up X clients. For example, Is $XAUTHORITY still set in the subshell? Can both users read the Xauthority file? -- brandon s. allbery[linux,solaris,freebsd,perl] [EMAIL PROTECTED] system administrator [WAY too many hats][EMAIL PROTECTED] electrical and computer engineering, carnegie mellon univ. KF8NH URGENT! E-xpedient nuked APK subdomains; kf8nh.apk.net is DEAD. Sorry. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PAM, X11, and su as a normal user? (fwd)
--On Friday, September 05, 2003 23:13:29 -0700 Steven G. Kargl [EMAIL PROTECTED] wrote: I have 2 accounts on my freebsd-current machine. I use startx to start X11 as user kargl. If I then su to user sgk, I cannot fire up X clients. For example, Try 'ssh -X [EMAIL PROTECTED]' instead of 'su kargl'. You shouldn't notice the overhead of the ssh protocol; and its a lot easier than messing around with the X11 authentication cruft. -Pat ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PAM, X11, and su as a normal user? (fwd)
Pat Lashley wrote: --On Friday, September 05, 2003 23:13:29 -0700 Steven G. Kargl [EMAIL PROTECTED] wrote: I have 2 accounts on my freebsd-current machine. I use startx to start X11 as user kargl. If I then su to user sgk, I cannot fire up X clients. For example, Try 'ssh -X [EMAIL PROTECTED]' instead of 'su kargl'. You shouldn't notice the overhead of the ssh protocol; and its a lot easier than messing around with the X11 authentication cruft. I don't quite understand your suggestion. I login as user kargl. I fire up X11 as user kargl with startx. I use su in a xterm to connect to my alter ego (su sgk). Now, as user sgk I want to use a X11 client such as nedit. AFAICT, it can't be done. If as user kargl, I do ssh -X [EMAIL PROTECTED] to login into the sgk account, I still can not use a X11 client. -- Steve http://troutmask.apl.washington.edu/~kargl/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PAM, X11, and su as a normal user? (fwd)
Brandon S. Allbery KF8NH wrote: On Sat, 2003-09-06 at 02:13, Steven G. Kargl wrote: I have 2 accounts on my freebsd-current machine. I use startx to start X11 as user kargl. If I then su to user sgk, I cannot fire up X clients. For example, Is $XAUTHORITY still set in the subshell? Can both users read the Xauthority file? $XAUTHORITY is not set. Both users use their defaults $HOME/.Xauthority. I used xauth to ensure the key for troutmask is the same for both users. -- Steve http://troutmask.apl.washington.edu/~kargl/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PAM, X11, and su as a normal user? (fwd)
On Sat, 2003-09-06 at 03:41, Steven G. Kargl wrote: Brandon S. Allbery KF8NH wrote: On Sat, 2003-09-06 at 02:13, Steven G. Kargl wrote: I have 2 accounts on my freebsd-current machine. I use startx to start X11 as user kargl. If I then su to user sgk, I cannot fire up X clients. For example, Is $XAUTHORITY still set in the subshell? Can both users read the Xauthority file? $XAUTHORITY is not set. Both users use their defaults $HOME/.Xauthority. I used xauth to ensure the key for troutmask is the same for both users. Then it ought to work. However, you also mentioned that ssh didn't work... which makes me wonder if it's actually using Xauth at all. What does xhost +localhost do (aside from annoy any Tk apps you might have running)? -- brandon s. allbery[linux,solaris,freebsd,perl] [EMAIL PROTECTED] system administrator [WAY too many hats][EMAIL PROTECTED] electrical and computer engineering, carnegie mellon univ. KF8NH URGENT! E-xpedient nuked APK subdomains; kf8nh.apk.net is DEAD. Sorry. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PAM, X11, and su as a normal user? (fwd)
--On Saturday, September 06, 2003 00:31:17 -0700 Steven G. Kargl [EMAIL PROTECTED] wrote: I don't quite understand your suggestion. I login as user kargl. I fire up X11 as user kargl with startx. I use su in a xterm to connect to my alter ego (su sgk). Now, as user sgk I want to use a X11 client such as nedit. AFAICT, it can't be done. If as user kargl, I do ssh -X [EMAIL PROTECTED] to login into the sgk account, I still can not use a X11 client. Hmm. That should work fine. I do it all the time. Check the log messages to see if the SSH daemon had any non-fatal complaints. The default config for SSHd used to disable X11 forwarding. Look in /etc/ssh/sshd_config for a line which sets X11Forwarding. Make sure it is set to 'yes'. (If the line is commented out, the value listed should be the default. You might want to un-comment it and set it to 'yes' just to be sure.) After changing sshd_config you will need to send a HUP signal to the running sshd to get it to re-load its config file. (kill -HUP `cat /var/run/sshd.pid`) Oh, wait, one more thing - the shell's rc scripts for user sgk must -NOT- modify the DISPLAY environment variable - it will be set properly by ssh. -Pat ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PAM, X11, and su as a normal user? (fwd)
Pat Lashley wrote: --On Saturday, September 06, 2003 00:31:17 -0700 Steven G. Kargl [EMAIL PROTECTED] wrote: I don't quite understand your suggestion. I login as user kargl. I fire up X11 as user kargl with startx. I use su in a xterm to connect to my alter ego (su sgk). Now, as user sgk I want to use a X11 client such as nedit. AFAICT, it can't be done. If as user kargl, I do ssh -X [EMAIL PROTECTED] to login into the sgk account, I still can not use a X11 client. Hmm. That should work fine. I do it all the time. Check the log messages to see if the SSH daemon had any non-fatal complaints. This appears to work now, but I had to delete sgk/.Xauthority and then merge user kargl/.Xauthority into sgk/.Xauthority. Perhaps, the old sgk/.Xauthority was somehow corrupt although xauth appeared to have no problems with it. -- Steve http://troutmask.apl.washington.edu/~kargl/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PAM, X11, and su as a normal user? (fwd)
Brandon S. Allbery KF8NH wrote: On Sat, 2003-09-06 at 03:41, Steven G. Kargl wrote: Brandon S. Allbery KF8NH wrote: On Sat, 2003-09-06 at 02:13, Steven G. Kargl wrote: I have 2 accounts on my freebsd-current machine. I use startx to start X11 as user kargl. If I then su to user sgk, I cannot fire up X clients. For example, Is $XAUTHORITY still set in the subshell? Can both users read the Xauthority file? $XAUTHORITY is not set. Both users use I take this back. $XAUTHORITY was pointing at the wrong .Xauthority file. their defaults $HOME/.Xauthority. I used xauth to ensure the key for troutmask is the same for both users. Then it ought to work. It works now that I that I fixed .cshrc to properly set $XAUTHORITY. Thanks for your help. -- Steve http://troutmask.apl.washington.edu/~kargl/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
PAM
Hello. I'm using Kerberos (heimdal) and off course it uses PAM. It's working well but I want to know if is the way to change kerberos password through PAM, not using kpasswd command? Or maybe it's even possible to synchronize kerberos and UNIX passwords? Can someone help me? Pawel Doncer. (please forgive me poor English) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
pam is chatty when logging in via ssh
On current as of about four hours ago, sshd spits the following to the console after a successful login: Feb 3 01:41:29 metropolis sshd[550]: in _openpam_check_error_code(): pam_sm_setcred(): unexpected return value 24 It seems harmless, but pam doesnt sound happy. I did notice that mergemaster updated /etc/pam/sshd by adding some krb5 lines. -- David P. Reese Jr. [EMAIL PROTECTED] -- C You shoot yourself in the foot. Assembler You try to shoot yourself in the foot, only to discover you must first invent the gun, the bullet, the trigger, and your foot. How to Shoot Yourself in the Foot http://www.m5p.com/~pravn/foot.html To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pam is chatty when logging in via ssh
On Mon, Feb 03, 2003 at 01:54:45AM -0800, David P. Reese Jr. wrote: On current as of about four hours ago, sshd spits the following to the console after a successful login: Feb 3 01:41:29 metropolis sshd[550]: in _openpam_check_error_code(): pam_sm_setcred(): unexpected return value 24 It seems harmless, but pam doesnt sound happy. I did notice that mergemaster updated /etc/pam/sshd by adding some krb5 lines. That's odd. Assuming that pam_krb5 is the module which is returning `24', I fixed that 4 days ago (Wed Jan 29 21:20:38 2003 UTC). Are you certain you have rebuilt pam_krb5? What is the output of `ident /usr/lib/pam_krb5.so' (should show revision 1.13 or later). The `four hours' does indeed correspond to DES's enabling of pam_krb5 by default in etc/pam.d/sshd. Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pam is chatty when logging in via ssh
On Mon, Feb 03, 2003 at 06:13:03AM -0600, Jacques A. Vidrine wrote:
On Mon, Feb 03, 2003 at 01:54:45AM -0800, David P. Reese Jr. wrote:
On current as of about four hours ago, sshd spits the following to the console
after a successful login:
Feb 3 01:41:29 metropolis sshd[550]: in _openpam_check_error_code():
pam_sm_setcred(): unexpected return value 24
It seems harmless, but pam doesnt sound happy. I did notice that mergemaster
updated /etc/pam/sshd by adding some krb5 lines.
That's odd. Assuming that pam_krb5 is the module which is returning
`24', I fixed that 4 days ago (Wed Jan 29 21:20:38 2003 UTC). Are you
certain you have rebuilt pam_krb5? What is the output of `ident
/usr/lib/pam_krb5.so' (should show revision 1.13 or later).
I cvsuped again to get des's recent changes and built world. After a fresh
install, when trying to ssh in i get:
Feb 3 05:02:36 metropolis sshd[3695]: in openpam_load_module(): no pam_krb5.so found
Feb 3 05:02:36 metropolis sshd[3695]: fatal: PAM: initialisation failed
It seems that {build,install}world forgot about pam_krb5.
[daver@metropolis:~]$ ll /usr/lib/pam_krb5*
ls: /usr/lib/pam_krb5*: No such file or directory
[daver@metropolis:~]$ cd /usr/src/lib/libpam/modules/pam_krb5/
[daver@metropolis:/usr/src/lib/libpam/modules/pam_krb5]$ sudo make clean obj all
install
...
[snip]
...
[daver@metropolis:/usr/src/lib/libpam/modules/pam_krb5]$ ll /usr/lib/pam_krb5*
lrwxr-xr-x 1 root wheel 13 Feb 3 05:05 /usr/lib/pam_krb5.so@ - pam_krb5.so.2
-r--r--r-- 1 root wheel 19432 Feb 3 05:05 /usr/lib/pam_krb5.so.2
Then we try to ssh into the machine and,
Feb 3 05:08:14 metropolis sshd[3750]: in openpam_load_module(): no pam_krb5.so found
Feb 3 05:08:14 metropolis sshd[3750]: fatal: PAM: initialisation failed
[daver@metropolis:~]$ ident /usr/lib/pam_krb5.so|grep pam_krb5
/usr/lib/pam_krb5.so:
$FreeBSD: src/lib/libpam/modules/pam_krb5/pam_krb5.c,v 1.15 2003/02/03 09:45:41
des Exp $
The `four hours' does indeed correspond to DES's enabling of pam_krb5
by default in etc/pam.d/sshd.
As a workaround, i can disable krb5 by commenting out the two lines in
/etc/pam.d/sshd which contain pam_krb5.so. Then ssh works just fine.
--
David P. Reese Jr. [EMAIL PROTECTED]
--
C
You shoot yourself in the foot.
Assembler
You try to shoot yourself in the foot, only to discover you must first
invent the gun, the bullet, the trigger, and your foot.
How to Shoot Yourself in the Foot
http://www.m5p.com/~pravn/foot.html
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: pam is chatty when logging in via ssh
David P. Reese Jr. [EMAIL PROTECTED] writes:
I cvsuped again to get des's recent changes and built world. After a fresh
install, when trying to ssh in i get:
Feb 3 05:02:36 metropolis sshd[3695]: in openpam_load_module(): no pam_krb5.so
found
Feb 3 05:02:36 metropolis sshd[3695]: fatal: PAM: initialisation failed
It seems that {build,install}world forgot about pam_krb5.
Oh drat, I am an idiot. I forgot that pam_krb5 is conditional on
MAKE_KERBEROS5.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Current Breaks courier-imap and/or pam?
Hi there, i was just wondering if anyone out there used Courier Imap on current using authpam? ... In the last couple days i upgraded both my current installation (from about 1 week old, to CURRENT current) and the courier-imap port. After this, i noticed that my courier imap stopped working... i tried downgrading to the last version 1.53 (i think) but that didnt' help one bit. the auth test program that comes w/ courier imap, seems to work fine. However when i login via telnet to the imap server, it acts as follows: -bash-2.05b$ telnet www 143 Trying 192.168.0.10... Connected to sadclown.net. Escape character is '^]'. * OK Courier-IMAP ready. Copyright 1998-2002 Double Precision, Inc. See COPYING for distribution information. 1 login sirfunk PASSWORD 1 NO Login failed. 2 logout * BYE Courier-IMAP server shutting down 2 OK LOGOUT completed Connection closed by foreign host. The only thing i think that could be goign wrong is something changed w/ PAM in Current recently? is that so?.. however SSH still works, so i'm somewhat confused. I'm SURE i'm using the correct password ect.. Anyone have a similar experiance, or any ideas? Thanks, Jeff Utter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Current Breaks courier-imap and/or pam?
Hi there, i was just wondering if anyone out there used Courier Imap on current using authpam? ... In the last couple days i upgraded both my current installation (from about 1 week old, to CURRENT current) and the courier-imap port. After this, i noticed that my courier imap stopped working... i tried downgrading to the last version 1.53 (i think) but that didnt' help one bit. the auth test program that comes w/ courier imap, seems to work fine. However when i login via telnet to the imap server, it acts as follows: -bash-2.05b$ telnet www 143 Trying 192.168.0.10... Connected to sadclown.net. Escape character is '^]'. * OK Courier-IMAP ready. Copyright 1998-2002 Double Precision, Inc. See COPYING for distribution information. 1 login sirfunk PASSWORD 1 NO Login failed. 2 logout * BYE Courier-IMAP server shutting down 2 OK LOGOUT completed Connection closed by foreign host. The only thing i think that could be goign wrong is something changed w/ PAM in Current recently? is that so?.. however SSH still works, so i'm somewhat confused. I'm SURE i'm using the correct password ect.. Anyone have a similar experiance, or any ideas? Thanks, Jeff Utter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Current Breaks courier-imap and/or pam?
On 2003-01-10 19:06:18 (-0500), Jeff Utter [EMAIL PROTECTED] wrote: Hi there, i was just wondering if anyone out there used Courier Imap on current using authpam? ... Yeps... In the last couple days i upgraded both my current installation (from about 1 week old, to CURRENT current) and the courier-imap port. After this, i noticed that my courier imap stopped working... i tried downgrading to the last version 1.53 (i think) but that didnt' help one bit. the auth test program that comes w/ courier imap, seems to work fine. However when i login via telnet to the imap server, it acts as follows: Read the PR I submitted about this a few hours ago: http://www.freebsd.org/cgi/query-pr.cgi?pr=46960 I remember noticing this behaviour a couple of weeks ago too, but being in a hurry then, I just fixed it and neglected to submit a PR :-/ The only thing i think that could be goign wrong is something changed w/ PAM in Current recently? is that so?.. however SSH still works, so i'm somewhat confused. I'm SURE i'm using the correct password ect.. Nope, the port overwrites /etc/pam.d/imap and /etc/pam.d/pop3 with broken 'defaults'. Just copy src/etc/pam.d/imap and src/etc/pam.d/pop3 into their respective spots on /etc and you should be fine. Anyone have a similar experiance, or any ideas? Me :-) - Philip -- Philip Paeps Please don't CC me, I am [EMAIL PROTECTED] subscribed to the list. In any organisation there will always be one person who knows what is going on. This person must be fired. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
PAM modules dependency on PAM library (was: Re: cvs commit: src/lib/libpam/modules/pam_unix pam_unix.c)
On Mon, Apr 08, 2002 at 02:49:04PM +0200, Dag-Erling Smorgrav wrote:
Ruslan Ermilov [EMAIL PROTECTED] writes:
You're right. I forgot to relink pam_ssh.so library, and the diff was
against the wrong revision. I will still commit the const poisoning
patch to libutil, as the impact turned out to be really low.
Thanks, const poisoning is a Good Thing [tm].
BTW, could you try to figure out a way we can split up the libpam
build so the modules can depend on libpam.so? What I'd like is:
1) build static modules
2) build static and dynamic libpam
3) build dynamic modules (with dependency on libpam.so)
or
1) build dynamic libpam
2) build modules (with dependency on libpam.so)
3) build static libpam
or something similar.
Uh oh, here is the version that seems to work. Once I'm confident it
passes the make release test (it has already passed the preliminary
make buildworld test), I intend to commit it.
Note that I'm not passing the _NO_LIBPAM_SO_YET to the depend stage
intentionally; otherwise, it results in incomplete .depend files.
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
Index: Makefile.inc1
===
RCS file: /home/ncvs/src/Makefile.inc1,v
retrieving revision 1.311
diff -u -r1.311 Makefile.inc1
--- Makefile.inc1 13 Nov 2002 13:49:29 - 1.311
+++ Makefile.inc1 14 Nov 2002 14:39:46 -
@@ -729,7 +729,8 @@
.endif
_prebuild_libs+= lib/libcom_err lib/libcrypt lib/libkvm lib/libmd \
- lib/libncurses lib/libopie lib/libradius lib/librpcsvc \
+ lib/libncurses lib/libopie lib/libpam lib/libradius \
+ lib/librpcsvc \
lib/libsbuf lib/libtacplus lib/libutil lib/libypclnt \
lib/libz lib/msun
@@ -755,7 +756,7 @@
_generic_libs+=usr.sbin/pcvt/keycap
.endif
-.for _lib in ${_startup_libs} ${_prebuild_libs} ${_generic_libs}
+.for _lib in ${_startup_libs} ${_prebuild_libs:Nlib/libpam} ${_generic_libs}
${_lib}__L: .PHONY
.if exists(${.CURDIR}/${_lib})
${ECHODIR} === ${_lib}; \
@@ -765,6 +766,16 @@
${MAKE} DIRPRFX=${_lib}/ install
.endif
.endfor
+
+# libpam is special: we need to build static PAM modules before
+# static PAM library, and dynamic PAM library before dynamic PAM
+# modules.
+lib/libpam__L: .PHONY
+ ${ECHODIR} === lib/libpam; \
+ cd ${.CURDIR}/lib/libpam; \
+ ${MAKE} DIRPRFX=lib/libpam/ depend; \
+ ${MAKE} DIRPRFX=lib/libpam/ -D_NO_LIBPAM_SO_YET all; \
+ ${MAKE} DIRPRFX=lib/libpam/ -D_NO_LIBPAM_SO_YET install
_startup_libs: ${_startup_libs:S/$/__L/}
_prebuild_libs: ${_prebuild_libs:S/$/__L/}
Index: lib/libpam/modules/Makefile.inc
===
RCS file: /home/ncvs/src/lib/libpam/modules/Makefile.inc,v
retrieving revision 1.13
diff -u -r1.13 Makefile.inc
--- lib/libpam/modules/Makefile.inc 13 May 2002 10:53:24 - 1.13
+++ lib/libpam/modules/Makefile.inc 14 Nov 2002 14:39:46 -
@@ -4,7 +4,6 @@
NOINSTALLLIB= yes
NOPROFILE= yes
-SHLIB_NAME?= ${LIB}.so.${SHLIB_MAJOR}
CFLAGS+= -I${PAMDIR}/include
CFLAGS+= -I${.CURDIR}/../../libpam
@@ -14,8 +13,12 @@
# This is nasty.
# For the static case, libpam.a depends on the modules.
# For the dynamic case, the modules depend on libpam.so.N
-# Punt for the time being until I can figure out how to do it.
-#DPADD+= ${LIBPAM}
-#LDADD+= -lpam
+.if defined(_NO_LIBPAM_SO_YET)
+NOPIC= YES
+.else
+SHLIB_NAME?= ${LIB}.so.${SHLIB_MAJOR}
+DPADD+=${LIBPAM}
+LDADD+=-lpam
+.endif
.include ../Makefile.inc
msg46674/pgp0.pgp
Description: PGP signature
Re: PAM modules dependency on PAM library (was: Re: cvs commit:src/lib/libpam/modules/pam_unix pam_unix.c)
Ruslan Ermilov [EMAIL PROTECTED] writes: Uh oh, here is the version that seems to work. Once I'm confident it passes the make release test (it has already passed the preliminary make buildworld test), I intend to commit it. Thanks! DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PAM modules dependency on PAM library (was: Re: cvs commit: src/lib/libpam/modules/pam_unix pam_unix.c)
On Thu, Nov 14, 2002 at 04:28:37PM +0100, Dag-Erling Smorgrav wrote: Ruslan Ermilov [EMAIL PROTECTED] writes: Uh oh, here is the version that seems to work. Once I'm confident it passes the make release test (it has already passed the preliminary make buildworld test), I intend to commit it. Thanks! I've tested it with i386 buildworld and cross-release of alpha. (i386 release died in buildkernel due to already fixed breakage in /sys/dev/pccard.) This is now committed. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg46709/pgp0.pgp Description: PGP signature
port security/p5-Authen-PAM doesn't build
Hi folks, I tried to build webmin on 5.0-current and the required port security/p5-Authen-PAM fails to build. At first there was an error in configuration which I have fixed and send the patch (PR ports/ports/44769). Now comes up another error which I'm not able to fix, because it seems that PAM.c has contains more than 1 source file and I never have seen such a thing before and don't know how to handle. Could please anyone applies the patch in his own environment and tries to help me to fix the port? Thanks in advance, Jens -- L i W W W i Jens Rehsack LW W W L i W W W W i nnnLiWing IT-Services L iW W W Wi n n g g i W W i n n g gFriesenstraße 2 06112 Halle g g g Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: [EMAIL PROTECTED] Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
PAM
Hi ! After last build of world (few days ago), PAM services started working and now I have trouble logging in with root, and starting X. Is there a way to disable PAM (whole one, not just some modules). Any help is appreciated. Andy ** * Aleksander Rozman - Andy * Fandoms: E2:EA, SAABer, Trekkie, Earthie * * [EMAIL PROTECTED] * Sentinel, BH 90210, True's Trooper, * *[EMAIL PROTECTED] * Heller's Angel, Questie, Legacy, PO5, * * Maribor, Slovenia (Europe) * Profiler, Buffy (Slayerete), Pretender* * ICQ-UIC: 4911125 * * PGP key available *http://www.atechnet.dhs.org/~andy/ * ** To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: xdm-Problems with PAM
On Mon, 12 Aug 2002 22:06:59 +0100 David Malone [EMAIL PROTECTED] wrote: On Mon, Aug 12, 2002 at 10:19:00PM +0200, Matthias Schuendehuette wrote: Aug 12 18:20:02 current : [dlerror: /usr/lib/pam_lastlog.so: Undefined symbol _openpam_log] Aug 12 18:20:02 current : adding faulty module: /usr/lib/pam_lastlog.so 'Known behaviour' or real problems? I recompiled xdm and the problem went away - I'm not sure if I should have thought about the problem more carefully. If xdm was compiled with old-pam, recompiling it is the only thing which helps, if it is already compield with new-pam, then I don't know what happens here. I don't have such problems with a Jul 22 kernel. Bye, Alexander. -- The dark ages were caused by the Y1K problem. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: xdm-Problems with PAM
Am Dienstag, 13. August 2002 14:42 schrieb Alexander Leidinger: On Mon, 12 Aug 2002 22:06:59 +0100 David Malone [EMAIL PROTECTED] wrote: On Mon, Aug 12, 2002 at 10:19:00PM +0200, Matthias Schuendehuette wrote: Aug 12 18:20:02 current : [dlerror: /usr/lib/pam_lastlog.so: Undefined symbol _openpam_log] Aug 12 18:20:02 current : adding faulty module: /usr/lib/pam_lastlog.so 'Known behaviour' or real problems? I recompiled xdm and the problem went away - I'm not sure if I should have thought about the problem more carefully. If xdm was compiled with old-pam, recompiling it is the only thing which helps, if it is already compield with new-pam, then I don't know what happens here. Ahemm... I must admit, I installed XFree4.2 from the 4.6-CDs... That obviously doesn't work - at least 'xdm' can't work, the rest of X seems to be OK. It's a pity - I can't download and compile the whole X-stuff with a only partly working i4b under -current on a 2 GB disk... Thank you both for your replies - Matthias -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) Powered by FreeBSD 4.6-STABLE To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
xdm-Problems with PAM
Hi, I set up xdm on my -current machine last Saturday and have the same problems still with todays (12.Aug) -current: When I try to login with 'xdm', the following errors come up: Aug 12 18:20:02 current : unable to dlopen(/usr/lib/pam_nologin.so) Aug 12 18:20:02 current : [dlerror: /usr/lib/pam_nologin.so: Undefined \ symbol _pam_verbose_error] Aug 12 18:20:02 current : adding faulty module: /usr/lib/pam_nologin.so Aug 12 18:20:02 current : unable to dlopen(/usr/lib/pam_unix.so) Aug 12 18:20:02 current : [dlerror: /usr/lib/pam_unix.so: Undefined \ symbol _pam_verbose_error] Aug 12 18:20:02 current : adding faulty module: /usr/lib/pam_unix.so Aug 12 18:20:02 current : unable to dlopen(/usr/lib/pam_opie.so) Aug 12 18:20:02 current : [dlerror: /usr/lib/pam_opie.so: Undefined \ symbol _openpam_log] Aug 12 18:20:02 current : adding faulty module: /usr/lib/pam_opie.so Aug 12 18:20:02 current : unable to dlopen(/usr/lib/pam_opieaccess.so) Aug 12 18:20:02 current : [dlerror: /usr/lib/pam_opieaccess.so: \ Undefined symbol _pam_verbose_error] Aug 12 18:20:02 current : adding faulty module: \ /usr/lib/pam_opieaccess.so Aug 12 18:20:02 current : unable to dlopen(/usr/lib/pam_lastlog.so) Aug 12 18:20:02 current : [dlerror: /usr/lib/pam_lastlog.so: Undefined symbol _openpam_log] Aug 12 18:20:02 current : adding faulty module: /usr/lib/pam_lastlog.so 'Known behaviour' or real problems? -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) Powered by FreeBSD 4.6-STABLE To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: xdm-Problems with PAM
On Mon, Aug 12, 2002 at 10:19:00PM +0200, Matthias Schuendehuette wrote: Aug 12 18:20:02 current : [dlerror: /usr/lib/pam_lastlog.so: Undefined symbol _openpam_log] Aug 12 18:20:02 current : adding faulty module: /usr/lib/pam_lastlog.so 'Known behaviour' or real problems? I recompiled xdm and the problem went away - I'm not sure if I should have thought about the problem more carefully. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Pam issue w/current yesterday and today: Undefined symbol _openpam_log
I've had the following issue with pam since yesterday's build. I thought that today's build would fix it and it hasn't. I know nothing about pam. Could someone give me a clue as to what I could do to solve this and be able to ssh into the machine? May 26 07:27:55 FreeBSD5 sshd[50568]: looking for 'sshd' in /etc/pam.d/sshd May 26 07:27:55 FreeBSD5 sshd[50568]: pam_nologin.so.2: /usr/lib/pam_nologin.so.2: Undefined symbol _openpam_log May 26 07:27:55 FreeBSD5 sshd[50568]: pam_nologin.so: /usr/lib/pam_nologin.so: Undefined symbol _pam_log May 26 07:27:55 FreeBSD5 sshd[50568]: no dynamic pam_nologin.so May 26 07:27:55 FreeBSD5 sshd[50568]: no pam_nologin.so found May 26 07:27:55 FreeBSD5 sshd[50568]: fatal: PAM initialisation failed[1]: failed to load module Thanks for any help, ed P.S. I've checked UPDATING, run mergemaster, I haven't rebooted since Wednesday to not loose established ssh connections. -- - http://insourcery.com - Mergence of Business and Technology a Griffin Plaza Partners, LLC Company To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Problems with ssh connections and Pam on today's current.
With this morning's build I have somehow lost ssh. I get the following error: May 12 10:11:03 worldinternet sshd[24224]: in openpam_load_module(): no pam_nologin.so found May 12 10:11:03 worldinternet sshd[24224]: fatal: PAM initialisation failed[1]: failed to load module May 12 10:27:32 worldinternet sshd[24674]: in openpam_load_module(): no pam_nologin.so found May 12 10:27:32 worldinternet sshd[24674]: fatal: PAM initialisation failed[1]: failed to load module It was so strange that I opened a port for telnet as a test and it works fine and the same pam modules are found. Have I done something wrong? I'm going back to look at the changes and see if I can catch what happened. Thanks for any suggestions. ed - http://insourcery.com - Mergence of Business and Technology a Griffin Plaza Partners, LLC Company To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: pam su
On 11-May-2002 Galen Sampson wrote: Hello all, After a 'make buildworld -DNO_WERROR` with sources today (05/10/02) and a mergemaster I am seeing the following on the console when I su: Don't mergemaster until after you've installworld'd. Is this normal? Welcome to current. It will go away when you get things back in sync again. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: pam su
On Sat, 11 May 2002, John Baldwin wrote: On 11-May-2002 Galen Sampson wrote: Hello all, After a 'make buildworld -DNO_WERROR` with sources today (05/10/02) and a mergemaster I am seeing the following on the console when I su: Don't mergemaster until after you've installworld'd. Yeah, I bumped into this on the TrustedBSD branch lately also. It goes side by side with the don't installworld until you mergemaster rule. And the very basic rule which is Don't run -CURRENT unless you not only want to shoot your feet, but have hot spares so you can shoot them with a lower recovery time. Is this normal? Welcome to current. It will go away when you get things back in sync again. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: pam su
Hello, --- Robert Watson [EMAIL PROTECTED] wrote: On Sat, 11 May 2002, John Baldwin wrote: On 11-May-2002 Galen Sampson wrote: Hello all, After a 'make buildworld -DNO_WERROR` with sources today (05/10/02) and a mergemaster I am seeing the following on the console when I su: Don't mergemaster until after you've installworld'd. Yeah, I bumped into this on the TrustedBSD branch lately also. It goes side by side with the don't installworld until you mergemaster rule. And the very basic rule which is Don't run -CURRENT unless you not only want to shoot your feet, but have hot spares so you can shoot them with a lower recovery time. All is well now. It turns out I ran the following sequence: buildworld (failed), buildworld -DNO_WERROR, shutdown now, buildkernel -DNO_WERROR, installkernel, installworld, shutdown -r now (su error after reboot), mergemaster (still error), and after a restart all was well. Don't mind shooting myself in the feet...just interested in the development process of large projects. I'm a senior CS major graduating in June. This is just a hobby. Galen Is this normal? Welcome to current. It will go away when you get things back in sync again. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: pam su
On Sat, 11 May 2002, Galen Sampson wrote: Don't mergemaster until after you've installworld'd. Yeah, I bumped into this on the TrustedBSD branch lately also. It goes side by side with the don't installworld until you mergemaster rule. And the very basic rule which is Don't run -CURRENT unless you not only want to shoot your feet, but have hot spares so you can shoot them with a lower recovery time. All is well now. It turns out I ran the following sequence: buildworld (failed), buildworld -DNO_WERROR, shutdown now, buildkernel -DNO_WERROR, installkernel, installworld, shutdown -r now (su error after reboot), mergemaster (still error), and after a restart all was well. Don't mind shooting myself in the feet...just interested in the development process of large projects. I'm a senior CS major graduating in June. This is just a hobby. Yeah, part of the gist of my message was that occasionally, there's no right upgrade path, you just have to slog through until your system appears to run normally again :-). Occasionally there are cycles of dependencies for upgrades -- you need a new users to install the files, but you don't get the new user until you run mergemaster. Or, you need a new binary to install a file via mergemaster, but you can't install the binary until mergemaster has created the config file for it. Last night I shot myself in the feet on my notebook by upgrading it to a recent -CURRENT with the trustedbsd_mac branch. The binary format for MAC labels changed, so init wouldn't exec, so the system would panic. If I booted the old kernel, because world was upgraded, all binaries setting credentials seg-faulted. Good stuff, experimental code. :-). Fortunately, it usually doesn't work out this way. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
pam su
Hello all, After a 'make buildworld -DNO_WERROR` with sources today (05/10/02) and a mergemaster I am seeing the following on the console when I su: May 10 22:14:38 su: using dynamic pam_nologin.so May 10 22:14:38 su: adding pam_nologin.so to cache May 10 22:14:38 su: pam_lastlog.so: pam_sm_authenticate(): Undefined symbol pam_sm_authenticate May 10 22:14:38 su: pam_lastlog.so: pam_sm_setcred(): Undefined symbol pam_sm_setcred May 10 22:14:38 su: pam_lastlog.so: pam_sm_acct_mgmt(): Undefined symbol pam_sm_acct_mgmt May 10 22:14:38 su: pam_lastlog.so: pam_sm_chauthtok(): Undefined symbol pam_sm_chauthtok May 10 22:14:38 su: using dynamic pam_lastlog.so May 10 22:14:38 su: adding pam_lastlog.so to cache May 10 22:14:38 su: using dynamic pam_deny.so May 10 22:14:38 su: adding pam_deny.so to cache May 10 22:14:38 su: releasing pam_nologin.so May 10 22:14:38 su: releasing pam_deny.so May 10 22:14:38 su: pam_start(su) succeeded May 10 22:14:38 su: calling pam_sm_authenticate() in pam_rootok.so May 10 22:14:38 su: User is not superuser May 10 22:14:38 su: pam_rootok.so: pam_sm_authenticate(): authentication error May 10 22:14:38 su: calling pam_sm_authenticate() in pam_self.so May 10 22:14:38 su: pam_self.so: pam_sm_authenticate(): authentication error May 10 22:14:38 su: calling pam_sm_authenticate() in pam_wheel.so May 10 22:14:38 su: Options processed May 10 22:14:38 su: Got target user: root uid: 0 May 10 22:14:38 su: Got user: galen May 10 22:14:38 su: User's primary uid, gid: 1000, 1000 May 10 22:14:38 su: Not superuser May 10 22:14:38 su: Checking group May 10 22:14:38 su: Got group: wheel May 10 22:14:38 su: pam_wheel.so: pam_sm_authenticate(): ignore this module May 10 22:14:38 su: calling pam_sm_authenticate() in pam_opie.so May 10 22:14:38 su: Options processed May 10 22:14:38 su: Got user: root May 10 22:14:38 su: pam_opie.so: pam_sm_authenticate(): authentication error May 10 22:14:38 su: calling pam_sm_authenticate() in pam_opieaccess.so May 10 22:14:38 su: pam_opieaccess.so: pam_sm_authenticate(): success May 10 22:14:38 su: calling pam_sm_authenticate() in pam_unix.so May 10 22:14:38 su: Options processed May 10 22:14:38 su: Got user: root May 10 22:14:38 su: Doing real authentication May 10 22:14:41 ip68-6-109-149 su: galen to root on /dev/ttyp0 Is this normal? regards, Galen Sampson __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
PAM doesn't allow to log-in when /var mounted ro
Hi, Subject says it all. I'm getting the following from the syslog: login: cannot open /var/log/lastlog: Read-only file system login: pam_open_session(): error in service module This violates POLA, therefore please fix ASAP. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PAM doesn't allow to log-in when /var mounted ro
On Thu, May 02, 2002 at 04:24:16PM +0300, Maxim Sobolev wrote: /var mounted ro sounds like a truly bad idea to me BTW. Hi, Subject says it all. I'm getting the following from the syslog: login: cannot open /var/log/lastlog: Read-only file system login: pam_open_session(): error in service module This violates POLA, therefore please fix ASAP. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message ---end of quoted text--- -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PAM doesn't allow to log-in when /var mounted ro
Wilko Bulte wrote: On Thu, May 02, 2002 at 04:24:16PM +0300, Maxim Sobolev wrote: /var mounted ro sounds like a truly bad idea to me BTW. This has nothing to do with the fact that PAM refuses authentification request when it's unable to open lastlog rw. -Maxim Hi, Subject says it all. I'm getting the following from the syslog: login: cannot open /var/log/lastlog: Read-only file system login: pam_open_session(): error in service module This violates POLA, therefore please fix ASAP. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message ---end of quoted text--- -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PAM doesn't allow to log-in when /var mounted ro
Wilko Bulte wrote: On Thu, May 02, 2002 at 04:24:16PM +0300, Maxim Sobolev wrote: /var mounted ro sounds like a truly bad idea to me BTW. You could rename it /invar... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PAM doesn't allow to log-in when /var mounted ro
Maxim Sobolev wrote: This has nothing to do with the fact that PAM refuses authentification request when it's unable to open lastlog rw. man pam.conf /optional ...then compare required, requisite, sufficient, and optional. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
passwd and PAM
I realize this probably isn't a -current issue, but since I don't have any experience with PAM I don't know for sure if it's just me or not. My problem is that the passwd command isn't doing anything, at all. I have the stock pam setup (/etc/pam.d, /etc/pam.conf deleted after running mergemaster). Running adduser will add a user with a password in master.passwd, but running passwd will not change the password, regardless if a password exists or is null. Also, if a user does have a password, with the stock setup not even root can change it without providing the correct previous password. This wasn't intentional was it? Chris To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: passwd and PAM
Great thanks! Chris On 26 Apr 2002, Dag-Erling Smorgrav wrote: bsd [EMAIL PROTECTED] writes: My problem is that the passwd command isn't doing anything, at all. Already fixed, cvsup and rebuild libpam. Also, if a user does have a password, with the stock setup not even root can change it without providing the correct previous password. This wasn't intentional was it? Yes and no. There are some complications regarding NIS. It's high on my list of things to fix. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: passwd and PAM
bsd [EMAIL PROTECTED] writes:
Great thanks!
You're welcome. The attached patch should fix the problem with passwd
asking root for the old password.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
//depot/user/des/pam/lib/libpam/modules/pam_unix/pam_unix.c#14 - /usr/src/lib/libpam/modules/pam_unix/pam_unix.c
--- /tmp/tmp.2741.0 Fri Apr 26 21:28:02 2002
+++ /usr/src/lib/libpam/modules/pam_unix/pam_unix.c Fri Apr 26 21:24:35 2002
@@ -313,6 +313,11 @@
PAM_LOG(PRELIM round);
+ if (getuid() == 0
+ (pwd-pw_fields _PWF_SOURCE) == _PWF_FILES)
+ /* root doesn't need the old password */
+ return (pam_set_item(pamh, PAM_OLDAUTHTOK, ));
+
if (pwd-pw_passwd[0] == '\0'
pam_test_option(options, PAM_OPT_NULLOK, NULL)) {
/*
@@ -338,7 +343,7 @@
PAM_LOG(UPDATE round);
retval = pam_get_authtok(pamh,
- PAM_AUTHTOK, old_pass, NULL);
+ PAM_OLDAUTHTOK, old_pass, NULL);
if (retval != PAM_SUCCESS)
return (retval);
PAM_LOG(Got old password);
Re: PAM OpenSSH: two incorrect last login
Bill Fenner [EMAIL PROTECTED] writes: You could either pretend that yflag was not set (what ache was suggesting) or set yflag if the year of the last login was not this year (possibly more useful). ...or always print the year. Does anybody have any patches? :) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PAM OpenSSH: two incorrect last login
Might, might not. ISTR strftime() can't correctly emulate ctime(), but some other format might be preferrable. Do you have a format string handy? I'd think something like what last does would be good. d_first = (*nl_langinfo(D_MD_ORDER) == 'd'); ... (void) strftime(ct, sizeof(ct), d_first ? (yflag ? %a %e %b %Y %R : %a %e %b %R) : (yflag ? %a %b %e %Y %R : %a %b %e %R), tm); except you probably want %T instead of %R if you want the seconds. You could either pretend that yflag was not set (what ache was suggesting) or set yflag if the year of the last login was not this year (possibly more useful). Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
