PAM Backend

[jrx-scientiam]

I'm requesting that a PAM backend be introduced into owncloud. In my scenario I use the following types of servers:

1. dovecot/postfix for email
2. sshd
3. owncloud
4. LDAP

These are run in different FBSD jails. In a *nix environment PAM is far easier to configure for LDAP support and can be scripted to download configuration files for fresh boxes which need to be authenticated against LDAP. Using the current LDAP backend you are required to configure an admin user and do far more work while maintaining a secondary infrastructure for both PAM and LDAP.

For security reasons PAM seems to be a better solution to segregate access to the LDAP server since no critical information really has to be stored in owncloud. The LDAP configuration would be in the background with PAM authentication against LDAP in an area that neither users nor owncloud needs to know about. The goal is to ensure that, if done properly, users that change their owncloud passwd would have it changed across the board for email, ssh, and owncloud (carddav/webdav/caldav). It would be incredibly helpful while allowing an admin to simply maintain the auth box.

[RobinMcCorkell]

For this to be effective ownCloud would have to have an NSS backend for user/group information. The problem with this approach is that ownCloud would be exposed to system users as well as domain users, which may not be suitable. Although a simple 'minUID' and 'minGID' option could fix this quite well.

Another thing to note, is that this will not work on systems that do not use PAM/NSS. Although with a modular design, this would be less of a problem, since the modules could just be disabled for non *nix systems.

Other than the above issues, I agree that a PAM backend would be very useful in certain circumstances.

[RobinJ1995]

Just a thought, but couldn't this be done by using the output of getent passwd and getent shadow? This works with local users, but also with NSS.

[RobinMcCorkell]

@RobinJ1995 That's the idea. How easy it is to implement is another thing entirely - we don't want to execute external programs if at all possible, much less parsing their output.

[RobinJ1995]

Either way, I was in need of something like this so I wrote my own extension for it. I hope it's also useful for others.

https://github.com/RobinJ1995/owncloud-user_getent

[AdamWill]

@RobinJ1995 please don't ever, ever, ever have a web server read the contents of shadow. just...no. you are not using PAM, you are extremely insecurely bypassing it.

http://apps.owncloud.com/content/show.php/Unix+user+backend?content=148406 is a somewhat less awful implementation of Unix account auth which already exists. It use pwauth, which is exactly designed to avoid you having to grant your web server root privileges to read the system password database, which oh god I still feel dirty just writing it down. https://code.google.com/p/pwauth/

also, pwauth is backed by PAM, which provides rather more fine-grained configuration and flexibility than just going direct to getent.

the standard way to do authentication against the system user database, I believe, would just be to have ownCloud understand the REMOTE_USER environment variable which is typically used by web servers for the purpose of letting the server provide authentication for running code (maybe OC already does this, I haven't checked). AIUI at least Apache, nginx, lighttpd and IIS all implement REMOTE_USER. So long as ownCloud is set up to read that if it's set, you can just configure HTTP authentication via a PAM module - mod_authnz_pam on Apache, for instance - and ownCloud can consume that information. This fairly commonly used and understood setup is only really fully suitable for authentication, AIUI, it doesn't handle access control very well or provide account information beyond the authenticated username, but for the purpose of pure authentication it does the job.

FreeIPA has a write-up that's focused on FreeIPA use cases, but does a decent job of explaining the system in general, at http://www.freeipa.org/page/Web_App_Authentication .

[AdamWill]

(edit: hm, I may be wrong there. needs more research.)

[RobinMcCorkell]

Does ownCloud have support for non-enumerated users and groups? Aka users and groups that cannot be 'listed', but can be checked if they exist individually? In that case, the pwauth method would work just fine, and it wouldn't need any getent magic going on to work. An option like that in LDAP could lead to some big performance improvements too: @blizzz

[RobinJ1995]

Judging by the class a user authentication backend plugin extends from,
yes, it should be perfectly possible.

On 9 September 2014 13:58, Robin McCorkell notifications@github.com wrote:

Does ownCloud have support for non-enumerated users and groups? Aka users
and groups that cannot be 'listed', but can be checked if they exist
individually? In that case, the pwauth method would work just fine, and it
wouldn't need any getent magic going on to work. An option like that in
LDAP could lead to some big performance improvements too: @blizzz
https://github.com/blizzz

—
Reply to this email directly or view it on GitHub
#10130 (comment).

[DeepDiver1975]

The 'Unix user backend' seems to fulfill the requirement -> closing

[AdamWill]

I think it doesn't quite fully meet @jrx-scientiam 's desires because it's a strictly one-way thing, pwauth just authenticates against pam. If you set a user password in OC it wouldn't propagate out as the user's new system password, pwauth isn't written to do that. I don't know what would be the right way to achieve that goal, and whether it's even something you'd want OC to do, but just noting it.

[tylla]

I would vote as well to re-open this issue, as 'Unix user backend' only does half of the job.
And it will never do 100% as the concept of pwauth doesn't allow any such functionality.
We would like to see full blown PAM support, as PAM is a really complex and feature-full, system it would really broaden the applicability of OC.

[C0NPAQ]

w0rd, issue is unsolved

[mitar]

+1

[mossholderm]

Agreed, PAM would be a better solution. Even in the case where LDAP is being used, PAM in conjunction with SSSD has a number of desirable features, like caching of responses. You could even set up a specific PAM service for owncloud, which could be completely disassociated from the normal user database (e.g. one in local files, the other in LDAP).

[IngwiePhoenix]

Hello! I am currently looking into trying to mapping OS.js ( https://www.os-js.org ) to OwnCloud's data, in order to utilize OwnCloud as a storage method. However, synchronizing the users between the two does not seem to be easy, which is why I thought to use PAM, in order to just use my system's account management.

Now, OS.js has already implemented a PAM based authentification method and also allows one to map a user's home folder. Since I am using system accounts, this mapping is done through /home. So, now I can log in with my system accounts (except root) and even see that user's files and stuff. However, OS.js does not have a dedicated file syncing capability yet, which is why I would like to add ownCloud to the mix. Basically, I hope that by enabling system user login in ownCloud and somehow telling it to download files to the user's $HOME folder, I would be able to synchronize my files through ownCloud and see them in OS.js. A proper adaption with the ownCloud API could be done later as well to allow the creation of shared links through ownCloud and the likes. But right now, I'd just like to link the files together.

What method can I use, or do I have to wait untill a full PAM-based authentification method is present in ownCloud?

(Sorry for bumping this thread, by the way!)