Jeffrey Hutzelman wrote:
Those tools are deprecated, and IMHO a pagsh.krb5 would be
inappropriate, unless we plan on shipping a complete suite of tools that
manage krb5 tickets, as we did for krb4.
Guess what Heimdal's pagsh does?
I follows the do-what-I-mean principle, in this case a
On Monday, January 16, 2006 09:48:18 AM +0100 Rainer Toebbicke
[EMAIL PROTECTED] wrote:
Jeffrey Hutzelman wrote:
Those tools are deprecated, and IMHO a pagsh.krb5 would be
inappropriate, unless we plan on shipping a complete suite of tools that
manage krb5 tickets, as we did for krb4.
It and its friends can be found at ftp://achilles.ctd.anl.gov/pub/DEE
pam_afs2-0.1.tar
gafstoken-0.3.tar
gssklog-0.11.tar
This is the beast I was referring to. I'm sorry I was too lazy to check
who created it and properly credit you.
The design goals of all of this was to keep AFS as far
Juha Jäykkä [EMAIL PROTECTED] writes:
Red Hat's pam_krb5 is not alone in having this problem;
see Debian bug #264902.
Thanks. This looks like exactly what I experienced. I never tried logging
in as another user, though, but since my shell got in the same PAG as
sshd, I assume the other
Yeah, currently you have to be careful to start sshd outside of a PAG
when using libpam-openafs-session (with, for instance, echo
Plus you need to make sure, your users end up in session-specific pag's.
While this is not strictly necessary, it's quite inconvenient to have two
(possibly
* Juha Jäykkä [2006-01-13 09:05:09 +0200]:
As what comes to kinit, its not setting the pag is a surprise to me after
all the praise of Heimdal's supposedly good integration with AFS.
Sometimes you want to start a new PAG, and sometimes you want to add or
refresh credentials in your current
Juha Jäykkä wrote:
It and its friends can be found at ftp://achilles.ctd.anl.gov/pub/DEE
pam_afs2-0.1.tar
gafstoken-0.3.tar
gssklog-0.11.tar
This is the beast I was referring to. I'm sorry I was too lazy to check
who created it and properly credit you.
The design goals of all of this
Sergio Gelato [EMAIL PROTECTED] writes:
I also like it that Heimdal's pagsh (kpagsh, in Debian) will generate a
new KRB5CCNAME, so that a subsequent kinit will not clobber the Kerberos
ccache of the parent process. OpenAFS's pagsh shouldn't (and doesn't) do
that since OpenAFS tries to be
I would like to see the OpenAFS people pick this up and distribute the
pam_afs2 or its equivalent with OpenAFS, as it is only used by AFS. The
discussions on the list lately are headed this way.
I support that idea. It is the only pam module which does things the Right
Way(tm). I did some
Juha Jäykkä wrote:
I would like to see the OpenAFS people pick this up and distribute the
pam_afs2 or its equivalent with OpenAFS, as it is only used by AFS. The
discussions on the list lately are headed this way.
I support that idea. It is the only pam module which does things the Right
Juha Jäykkä [EMAIL PROTECTED] writes:
Debian's pam_krb5.so (where does this originate from?)
http://www.squishy.cc/software/pam-krb5/
Will leak tokens (not create a PAG) when authenticating with pubkey
This isn't a problem that pam-krb5 should be solving; instead, it should
be dealt with in
On Thursday, January 12, 2006 06:41:21 PM -0800 Russ Allbery
[EMAIL PROTECTED] wrote:
Jeffrey Hutzelman [EMAIL PROTECTED] writes:
However, they do it that way not as part of some misguided attempt at
security, but because of the constraints imposed by the way their SSH
protocol parser
On Friday, January 13, 2006 11:00:14 AM -0800 Russ Allbery
[EMAIL PROTECTED] wrote:
Sergio Gelato [EMAIL PROTECTED] writes:
I also like it that Heimdal's pagsh (kpagsh, in Debian) will generate a
new KRB5CCNAME, so that a subsequent kinit will not clobber the Kerberos
ccache of the parent
On Fri, 13 Jan 2006 09:12:14 +0200
Juha Jäykkä [EMAIL PROTECTED] wrote:
I think that pam_krb5afs.so no longer exists, [...]
pam_krb5afs exists at least in Debian for Heimdal clients. I have a
few
machines with Heimdal running it now, and it appears to work fine.
And in which package? I
Jeffrey Hutzelman [EMAIL PROTECTED] writes:
Those tools are deprecated, and IMHO a pagsh.krb5 would be
inappropriate, unless we plan on shipping a complete suite of tools that
manage krb5 tickets, as we did for krb4.
The problem is, pagsh.krb5 is a program that should alter both AFS and
Russ Allbery wrote:
Jeffrey Hutzelman [EMAIL PROTECTED] writes:
No it doesn't. All it needs is a relatively simple library which
provides a way to check for the presence of AFS and to make AFS system
calls, particularly setpag and pioctl.
Conveniently, heimdal comes with such a
I would have thought pam_krb5.so [1] does this by itself, but
It's only a PAM module for Kerberos. It doesn't know anything about
AFS.
I disagree. From its README:
o tokens
Create a new AFS PAG and obtain AFS tokens during the authentication
phase. By default, tokens are obtained for the
Ah, okay, I didn't realize that.
It's the best working solution I have been able to come up with. Its being
monolithic makes it non-ideal, but it seems to work fine. It even parses
krb5.conf's [appdefaults] pam = { ... } and is easy to configure. It even
allows me to set non-default
about AFS, or PAGs. But some do, so look for a pam_krb5afs.so
I think that pam_krb5afs.so no longer exists, at least the README of
RedHat's pam_krb5.so says
This is a major rewrite of pam_krb5afs. Call it 2.0, for lack of a better term.
o Compared to the earlier releases, this tree builds a
Juha Jäykkä wrote:
Suggestions?
I have one: there is such a thing as pam_afs2.so, which I found somewhere,
which can run arbitrary programs as part of PAM login process (at auth
stage, if I recall). It can do afslog (and it even comes with its own
afs5log of which I know nothing) instead
* Juha Jäykkä [2006-01-11 13:19:57 +0200]:
I would have thought pam_krb5.so [1] does this by itself, but
It's only a PAM module for Kerberos. It doesn't know anything about
AFS.
I disagree. From its README:
o tokens
Create a new AFS PAG and obtain AFS tokens during the
Sergio Gelato [EMAIL PROTECTED] writes:
If you're using privilege separation in OpenSSH, the setpag() that's
done in the authentication phase may not affect the user session (unless
they've managed to make that process a descendant of the one in which
the authentication takes place, or
On Thu, 12 Jan 2006 00:08:50 +0200
Juha Jäykkä [EMAIL PROTECTED] wrote:
I think that pam_krb5afs.so no longer exists, [...]
pam_krb5afs exists at least in Debian for Heimdal clients. I have a few
machines with Heimdal running it now, and it appears to work fine.
-zeroguy
Juha Jäykkä [EMAIL PROTECTED] writes:
I would have thought pam_krb5.so [1] does this by itself, but apparently
I am mistaken (again).
It's only a PAM module for Kerberos. It doesn't know anything about AFS.
While it would be relatively easy to write a small pam module to handle
the
Juha Jäykkä [EMAIL PROTECTED] writes:
I disagree. From its README:
o tokens
Create a new AFS PAG and obtain AFS tokens during the authentication
phase. By default, tokens are obtained for the local cell (and the cell
which contains the user's home directory, if they're not the same).
Juha Jäykkä wrote:
sshd won't leak this token to the user if your PAM setup is appropriate.
You have to make sure that the user is put into their own PAG as part of
the session initialization process, even if they don't get a token.
I would have thought pam_krb5.so [1] does this by itself,
On Wed, 11 Jan 2006 00:45:38 -0800
Russ Allbery [EMAIL PROTECTED] wrote:
Soon we'll have the OpenAFS aklog packaged for Debian.
Russ, just wondering, is there any specific time or a specific release
you're planning on packaging it (like, maybe 1.4.1?) Will it remain a
separate package?
Juha Jäykkä [EMAIL PROTECTED] writes:
Ah, okay, I didn't realize that.
It's the best working solution I have been able to come up with. Its
being monolithic makes it non-ideal, but it seems to work fine. It even
parses krb5.conf's [appdefaults] pam = { ... } and is easy to
configure. It
Russ Allbery wrote:
Juha Jäykkä [EMAIL PROTECTED] writes:
You probably don't really need to do this, as Heimdal comes with an afslog
that should work fine -- although, I don't know if it supports the -setpag
flag to set a PAG for the parent process. Unfortunately, doing PAM
properly
Douglas E Engert [EMAIL PROTECTED] writes:
Its actually knowing what the syscall is that AFS uses to set the PAG.
and what to do if the syscall fails. You don't really have to link in
any AFS library. The pam_afs2 does this, and uses no AFS or Kerberos
libs.
It would be nice AFS provided a
zeroguy [EMAIL PROTECTED] writes:
Russ Allbery [EMAIL PROTECTED] wrote:
Soon we'll have the OpenAFS aklog packaged for Debian.
Russ, just wondering, is there any specific time or a specific release
you're planning on packaging it (like, maybe 1.4.1?)
1.4.1, yes.
Will it remain a separate
On Wednesday, January 11, 2006 02:33:37 PM -0800 Russ Allbery
[EMAIL PROTECTED] wrote:
You probably don't really need to do this, as Heimdal comes with an afslog
that should work fine -- although, I don't know if it supports the -setpag
flag to set a PAG for the parent process.
Jeffrey Hutzelman [EMAIL PROTECTED] writes:
No it doesn't. All it needs is a relatively simple library which
provides a way to check for the presence of AFS and to make AFS system
calls, particularly setpag and pioctl.
Conveniently, heimdal comes with such a library; it's called libkafs and
On Wednesday, January 11, 2006 03:15:56 PM -0800 Russ Allbery
[EMAIL PROTECTED] wrote:
Jeffrey Hutzelman [EMAIL PROTECTED] writes:
No it doesn't. All it needs is a relatively simple library which
provides a way to check for the presence of AFS and to make AFS system
calls, particularly
Jeffrey Hutzelman [EMAIL PROTECTED] writes:
Russ Allbery [EMAIL PROTECTED] wrote:
Certainly such a library would be useful. If someone wants to
implement it without all of the dependencies that Heimdal libkafs has,
I'd be all in favor of it. Heimdal's libkafs has significant
dependencies
On Wednesday, January 11, 2006 04:00:47 PM -0800 Russ Allbery
[EMAIL PROTECTED] wrote:
Jeffrey Hutzelman [EMAIL PROTECTED] writes:
Russ Allbery [EMAIL PROTECTED] wrote:
Certainly such a library would be useful. If someone wants to
implement it without all of the dependencies that
Jeffrey Hutzelman wrote:
Support for directory
entries pointing to files in located in *other* volumes (and with what
type of ACL semantics)?
Huh? Why would we do that?
Directory entries describe files within a single directory.
Well, you're redesigning so this is the time to ask why
sshd won't leak this token to the user if your PAM setup is appropriate.
You have to make sure that the user is put into their own PAG as part of
the session initialization process, even if they don't get a token.
I would have thought pam_krb5.so [1] does this by itself, but apparently I
am
Jeffrey Hutzelman wrote:
Getting a directory format that would be backward compatible with
existing clients was a tricky bit of work, but I think we succeeded.
At what state? Source code or design document?
Support for directories with 64k-odd entries? Support for directory
entries
On Monday, January 09, 2006 09:45:46 AM +0100 Rainer Toebbicke
[EMAIL PROTECTED] wrote:
Jeffrey Hutzelman wrote:
Getting a directory format that would be backward compatible with
existing clients was a tricky bit of work, but I think we succeeded.
At what state? Source code or design
Juha Jäykkä [EMAIL PROTECTED] writes:
Seems to me, then, that PAM is lacking proper handling of user
authorization. It may not be much different from handling authorization
and authentication together, but looks like having different hooks for
these different things might be a good idea. Go
Conceptually, yes.
In the PAM world, authorization checks such as this are done as part of
the authenticate operation, not the account management operation.
Seems to me, then, that PAM is lacking proper handling of user
authorization. It may not be much different from handling authorization
authentication identities to AFS ID's), the AFS directory format (to
support unicode filenames and 64K files per directory),
Does the directory format have to change for unicode? I'm pretty sure it
will hold utf-8 with no changes. Other things would have to change of
course.
Jim Rees wrote:
authentication identities to AFS ID's), the AFS directory format (to
support unicode filenames and 64K files per directory),
Does the directory format have to change for unicode? I'm pretty sure it
will hold utf-8 with no changes. Other things would have to change of
This appears to be a security decision based primarily on a technical
limitation in AFS.
Sure was; I never said otherwise. I fully admit it's not ideal, but I
have to work with the tools that I have, not the ones that I wish I
had. Certainly everybody makes those kinds of decisions every day.
In message [EMAIL PROTECTED],Jeffrey Altman writes:
we should also make changes to support multiple data streams per file
just curious. could you elaborate on this one a bit? are you talking
about versioning, resource forks, or something else?
___
Therefore, for a Unicode
directory entry there must be two strings stored: the normalized string
that is used for directory searches and a display string that is the
string the user entered.
Is there precedent for this? Do any other unicode based file systems do it
this way?
Jim Rees wrote:
Therefore, for a Unicode
directory entry there must be two strings stored: the normalized string
that is used for directory searches and a display string that is the
string the user entered.
Is there precedent for this? Do any other unicode based file systems do it
chas williams - CONTRACTOR wrote:
In message [EMAIL PROTECTED],Jeffrey Altman writes:
we should also make changes to support multiple data streams per file
just curious. could you elaborate on this one a bit? are you talking
about versioning, resource forks, or something else?
Traditional
Jim Rees [EMAIL PROTECTED] writes:
Therefore, for a Unicode directory entry there must be two strings
stored: the normalized string that is used for directory searches and
a display string that is the string the user entered.
Is there precedent for this? Do any other unicode based
On Friday, January 06, 2006 09:16:40 AM -0500 Jim Rees [EMAIL PROTECTED]
wrote:
authentication identities to AFS ID's), the AFS directory format (to
support unicode filenames and 64K files per directory),
Does the directory format have to change for unicode? I'm pretty sure it
will
On Friday, January 06, 2006 10:31:10 AM -0500 Jeffrey Altman
[EMAIL PROTECTED] wrote:
At the same time the directory format is extended to support Unicode
we should also make changes to support multiple data streams per file
and a method of supporting additional file attributes.
Those
Most of our users will place files in their home directory, even in the top
level, expecting them to be secure. Additionally, I fully expect that most
users will leave permissions with the default settings. In this case, when a
user creates a directory it inherits the ACL privileges of its
On Thursday 05 January 2006 7:32 am, Ken Hornstein wrote:
Given the choice between files possibly being world-readable and users
having to expose their password for every login (even if you're
encrypting the session, we've learned the hard way that isn't enough
anymore), we decided to go with
I have found this discussion very interesting, and it appears many sites
are living with the l symlinks for .k5login to a directory with rl.
mostly because that is the simplest thing to do.
But after reading Jeff Hutzelman's note from earlier today, maybe the
problem is not with AFS but with
At 03:30 PM 1/5/2006, Lester Barrows wrote:
On Thursday 05 January 2006 7:32 am, Ken Hornstein wrote:
This appears to be a security decision based primarily on a technical
limitation in AFS. The per-directory ACL limitation itself was more or less
what I was discussing, as it has caused me more
On Thursday, January 05, 2006 04:21:52 PM -0500 Rodney M Dyer
[EMAIL PROTECTED] wrote:
Wasn't there some talk about the DFS code being opened? And didn't DFS
have file level ACLs? Could any of that code be ported to AFS, or is
there already a project underway for file level ACLs in AFS?
Hi!
We have a nicely working Heimdal + LDAP database (the OS is Debian/GNU
Linux), providing user authentication and authorization. Now, we would
like to move from somewhat unreliable NFS to something more robust - and
especially something more firewall friendly - and are considering OpenAFS.
Try this:
/afs/italia/project/bigbox/e3/i386/updates/openssh*
(You will have to install the right /etc/krb5.conf and /etc/krb5.keytab).
Andrei.
On 1/4/06, Juha Jäykkä [EMAIL PROTECTED] wrote:What is The Way to have all three (afs, heimdal and sshd) work together?
/afs/italia/project/bigbox/e3/i386/updates/openssh*
You don't happen to have the sources around? I can convert the binary rpms
to binary debs, but that will eventually lead to library incompatibilities
and such. What kind of modifications have you done to the ssh server?
In my opinion, the
Juha Jäykkä [EMAIL PROTECTED] writes:
In my opinion, the problem is pam_krb5.so, which checks the .k5login
file in pam_sm_authenticate(). Its own documentation says it only checks
.k5login in pam_sm_acct_mgmt(), but this is incorrect. I am not sure
this is a bug, though, and therefore haven't
Douglas E Engert [EMAIL PROTECTED] writes:
The sshd could accept a forwarded ticket for the sole purpose of using
it to get an AFS token so the sshd could access the .k5login file before
the krb5_kuserok was called (There might be some other dot files that
could also be accessed early.)
Russ Allbery wrote:
Douglas E Engert [EMAIL PROTECTED] writes:
The client is, understandably, not going to forward the ticket until after
the authentication step is complete, so what this basically means is
authenticating the user, accepting the forwarded ticket, and then
reauthenticating the
Russ Allbery wrote:
Douglas E Engert [EMAIL PROTECTED] writes:
The sshd could accept a forwarded ticket for the sole purpose of using
it to get an AFS token so the sshd could access the .k5login file before
the krb5_kuserok was called (There might be some other dot files that
could also be
Any distributed file system has the same problem, if files in the home
directory need to be accessed during login. NFSv4 may have to address the
same problems.
The problem with afs is that you can't put an acl on a file. NFSv4 doesn't
have this problem.
Jim Rees wrote:
Any distributed file system has the same problem, if files in the home
directory need to be accessed during login. NFSv4 may have to address the
same problems.
The problem with afs is that you can't put an acl on a file. NFSv4 doesn't
have this problem.
The problem
On Wednesday 04 January 2006 12:42 pm, Douglas E. Engert wrote:
The problem is not about ACLs on files or directories, it more about
allowing world readable access to what some might consider sensitive data.
I still would not like the .k5login world readable.
What I meant about NFS vs AFS is
Jeffrey Altman [EMAIL PROTECTED] writes:
Processing of the .k5login file is not an authentication operation, it
is an authorization operation. Therefore, it is perfectly reasonable
for the client to mutually authenticate with a server, forward a ticket
and then have access rejected due to an
Lester Barrows [EMAIL PROTECTED] writes:
With AFS we have to decide whether to allow the world to read the entire
top level of a home directory, or to always require the username and
password for each login.
No, you only have to decide whether to allow the world to *list* the
entire top level
This should be a reasonable approach. For all machines that
are being logged into using gssapi krb5, those machines must
have been issued a Kerberos principal and they must have a
keytab. Assign the principal an AFS ID and then use a program
such as kstart to obtain and maintain a AFS token in
* Douglas E. Engert [2006-01-04 14:19:56 -0600]:
Russ Allbery wrote:
Douglas E Engert [EMAIL PROTECTED] writes:
The sshd could accept a forwarded ticket for the sole purpose of using
it to get an AFS token so the sshd could access the .k5login file before
the krb5_kuserok was called (There
On Wednesday 04 January 2006 1:30 pm, Ken Hornstein wrote:
FWIW, we choose the exact opposite option (world readable home directory)
for the exact same reason (lack of confidence in the vigilance of users).
--Ken
Most of our users will place files in their home directory, even in the top
On Wednesday 04 January 2006 1:36 pm, Russ Allbery wrote:
No, you only have to decide whether to allow the world to *list* the
entire top level of a home directory. Read is not required.
That's still more privileges than we can give out based on our security
policy, since this is the default
Lester Barrows [EMAIL PROTECTED] writes:
On Wednesday 04 January 2006 1:36 pm, Russ Allbery wrote:
No, you only have to decide whether to allow the world to *list* the
entire top level of a home directory. Read is not required.
That's still more privileges than we can give out based on our
Sergio Gelato [EMAIL PROTECTED] writes:
This is straying off-topic, but I'd argue that the default behaviour of
a PAM module should still be the correct one: call krb5_kuserok() from
pam_sm_acct_mgmt() only. Then one can add options to work around bugs in
important applications.
The problem
On Wednesday, January 04, 2006 03:02:20 PM -0500 Jeffrey Altman
[EMAIL PROTECTED] wrote:
Russ Allbery wrote:
Douglas E Engert [EMAIL PROTECTED] writes:
The client is, understandably, not going to forward the ticket until
after the authentication step is complete, so what this basically
On Wednesday 04 January 2006 1:48 pm, Jeffrey Altman wrote:
This should be a reasonable approach. For all machines that
are being logged into using gssapi krb5, those machines must
have been issued a Kerberos principal and they must have a
keytab. Assign the principal an AFS ID and then use
On Wednesday, January 04, 2006 04:30:37 PM -0500 Ken Hornstein
[EMAIL PROTECTED] wrote:
With AFS we have to decide whether to allow the world to read the entire
top level of a home directory, or to always require the username and
password for each login. At the moment I've chosen the
On Wednesday, January 04, 2006 02:55:19 PM -0800 Russ Allbery
[EMAIL PROTECTED] wrote:
As far as the screensavers' not running the account stack, I'd be more
worried about what happens when a Kerberos password has just expired
than about krb5_kuserok() being skipped: after all, the initial
Jeffrey Hutzelman [EMAIL PROTECTED] writes:
Russ Allbery [EMAIL PROTECTED] wrote:
The screen savers that I've looked at actually explicitly don't call
the account stack (or call it and ignore its return status) because
they don't want to lock out users with expired accounts.
Don't ask me;
Sergio Gelato wrote:
* Douglas E. Engert [2006-01-04 14:19:56 -0600]:
Russ Allbery wrote:
Douglas E Engert [EMAIL PROTECTED] writes:
The sshd could accept a forwarded ticket for the sole purpose of using
it to get an AFS token so the sshd could access the .k5login file before
the
* Russ Allbery [2006-01-04 14:55:19 -0800]:
Sergio Gelato [EMAIL PROTECTED] writes:
As far as the screensavers' not running the account stack, I'd be more
worried about what happens when a Kerberos password has just expired
than about krb5_kuserok() being skipped: after all, the initial
On Wednesday, January 04, 2006 05:31:15 PM -0600 Douglas E. Engert
[EMAIL PROTECTED] wrote:
Exactly where in the PAM stack do you want
to obtain (and, if need be, discard) this extra token? pam_open_session()
I am not sure. It has to be after the GSSAPI or pam_authenticate has a TGT
On Thursday, January 05, 2006 01:05:19 AM +0100 Sergio Gelato
[EMAIL PROTECTED] wrote:
* Russ Allbery [2006-01-04 14:55:19 -0800]:
Sergio Gelato [EMAIL PROTECTED] writes:
As far as the screensavers' not running the account stack, I'd be more
worried about what happens when a Kerberos
84 matches
Mail list logo
