Hello Joerg!
On Wed, 25 Dec 2002, Joerg Sommer wrote:
> Igmar Palsenberg <maillist@jdimedia.nl> wrote:
> > Ok.. We want to able to specify where to find the runtime config.
>
> I can't understand, what you will win with this? What processes it should
> affect? It's a good thing, that root can unlock [vx]lock. Otherwise it
> must kill the users session if he has locked his session and run away.
It is totaly different question if a localhost superuser can unlock
session locks.
Remember, a user *can* run a program of her choice to lock her session (or
even easily lock herself out!), so it is a policy issue, not a technical
one.
> And from where the user knows what must stand in the
> config file?
It is perfectly ok if I as a "sysadmin" provides the configs usable by the
users. You see, my users (including myself) do use their files and the
program environment across administrative boundaries.
So while I am a sysadm "here" I am not a sysadm "there", still both my
users and myself want to use the same session locking program (from the
same meny and from the same binary on a trustable distributed file
system). Technically it is no problem - just hack a program, but I want to
use the existing - good - tools). Alas, it is impossible to use PAM for
that matter, yet.
The sysadmins "there" trust my binaries to be run on their hosts, but they
are not willing to make changes in /etc according to my wishes!
> If your system works with something like ldap or nis, the
> user must take the modules for this. Who tells this him? The admin and
Sure, it should be an expert who configures the things for the users,
but it should be the users who can choose the configured tool and run it,
even on systems without /etc/pam.* or /lib/security ...
> thats a great price of work. And your system become insecurer, if
> anybody, who doesn't know anything about pam, can configure pam.
The users can run almost anything, including a troyan or say "sleep 1000"
as a lock command :-)
Again, I advocate just for the possibility for the users to run a
pam-aware application that does not depend on the *local host*
superuser.
It does not imply that the user herself has to configure the application.
It may be a sysadm who is not the local superuser on all the hosts the
user may use, but still is a trusted party.
> So I only see a possibility for something like [xv]lock with the
> disadvantages named above.
Neither the users nor sysadmins have to accept any disadvantages,
a "runtime config" can be exactly as it has been, if you want it that way.
But it would open some possibilities unavailable now.
One extra hypothetical but handy example:
- on a restricted machine run one sshd that listens on all
interfaces and uses a restrictive pam setup,
run another one that listens on local interface only
but allows test accounts to start sessions
You can do a similar thing by tweaking sshd_config, but as soon as you
have more than one service you would use in that way (xdm? samba? imap?)
you may find PAM to be very handy. Even with sshd only, PAM is a way more
powerful than sshd_config.
Best regards,
--
Ivan
_______________________________________________
Pam-list@redhat.com
https://listman.redhat.com/mailman/listinfo/pam-list
