From: API <api...@ig...> - 2007-09-20 06:51:36
|
> I also saw this, when I was testing fisterra-repair. That's because > fisterra-repair always tries to install a file in /etc/pam.d, it doesn't > matter what prefix or options you pass to the configure script. > Look at this file: /src/server/etc/Makefile.am > That directory is hard-coded in a line like: pamconfdir = /etc/pam.d > There are two options, install this always as root, or to change that line. I > think that folder should depend on an option passed to the configure script. Well, you could made this to solve this concrete problem, but there are a problem You can configure other directories because is fisterra who use this, like the serverconfdir in the same Makefile.am. If we are compiling in a local directory, we can change the directory, and fisterra will find the file correctly. But this directory is hardcoded because who will use the file "fisterra" is the pam module, and to work properly, the file is needed to be on this directory. If we configure this directory to a local one, we can solve the problem making a `make install`, but the authentication will fail if we try to execute this. Currently, the auth module (on fisterra-bmodules-auth) uses pam to make the authentication, and uses the "hard-coded" file called "fisterra". In this way we can configure the authentication very easy, as there are several pam modules: using a file, using a ldap, etc. In this case, it is configured to use a pwd file. In theory, thinking in the project as an open project, it is simply an configuration example, there are any point on documentation that says that?, that explain how configure and how works the authentication, and that this is only a example? Another point: there are a problem with this implementation. As I say, the fisterra-bmodule-auth module uses the `fisterra` file to authenticate. This has a problem: what happens if you have several applications based on fisterra? (ie: fisterra-repair and fisterra-distribution). The problem is that to authenticate you'll be sharing the same authentication file. Well, when you start to work, you can have different acls, as this in on database, but at first, to authenticate, you share the pam.d fisterra, as it is used on fisterra-bmodules. Looking a cvs log at Makefile.am, you can see that at begining this authentication file was on fisterra-bmodules. This was because is shared, but was moved because in theory you use a concrete file for each application. But as I say, it is shared. If we make each concrete app to install his fisterra file, each one will be replacing the fisterra file of the others. This "shared approach" has sense if all the fisterra applications on a machine share his users, but Im not sure if we can suppose this at this moment. Other problem with this approach is that it is difficult to add new users, although with the acls, it is difficult to add users (in fact, this is more a "role" approach). Should be reviewed the fisterra-bmodule-auth? For example: in others applications based on fisterra, we don't use fisterra-bmodules-auth to authenticate, the app implements the authentication himself, and uses the database to manage the users that can authenticate, and to add users. === API (api...@ig...) |