Scott Cantor canto...@osu.edu writes:
Note that we can't just use umask 177 in the Debian version of this script
since Debian runs shibd as a non-root user and then won't be able to read
the certificate. For Debian, we should set the group ownership to the
shibd user we create and make the
Don't you think it's kind of an openssl bug to create the key material
with full permissions? Shouldn't it creat(keyfile, 0600)?
Would be nice I suppose.
This aside, I'd recommend working around the issue by creating the key
file beforehand with restricted permissions, and not touching
On Fri, Mar 05, 2010 at 10:01:23AM -0800, Russ Allbery wrote:
Ferenc Wagner wf...@niif.hu writes:
How should we proceed with this bug? I'm not sure it warrants a
security update, so I didn't want to push this patch.
It doesn't really warrant a security update, I think. However, we
Ferenc Wagner wf...@niif.hu writes:
Upstream fixed this by using umask 177.
Russ,
How should we proceed with this bug? I'm not sure it warrants a
security update, so I didn't want to push this patch.
Thanks,
Feri.
From 8012fbf3cfb48df91ff26dc30cda23fb739386e7 Mon Sep 17 00:00:00 2001
From:
Ferenc Wagner wf...@niif.hu writes:
How should we proceed with this bug? I'm not sure it warrants a
security update, so I didn't want to push this patch.
It doesn't really warrant a security update, I think. However, we should
apply it to the unstable shibboleth-sp2 and do another upload. I
Note that we can't just use umask 177 in the Debian version of this script
since Debian runs shibd as a non-root user and then won't be able to read
the certificate. For Debian, we should set the group ownership to the
shibd user we create and make the file group-readable.
If there's a
Scott Cantor canto...@osu.edu writes:
Note that we can't just use umask 177 in the Debian version of this script
since Debian runs shibd as a non-root user and then won't be able to read
the certificate. For Debian, we should set the group ownership to the
shibd user we create and make the
Thank you for the offer! I think it's going to be a bit tricky for you to
do something upstream that will also work in Debian without modifications,
since you won't be able to rely on the group that we're creating as part
of the package installation, so I suspect we should probably carry a
Actually, I think I was confusing your original umask fix with this
submitted patch:
https://bugs.internet2.edu/jira/browse/SSPCPP-281
That has a -u option for controlling the user, and I suppose having a group
option would make sense also.
It would help if folks could collaborate and suggest
Processing commands for cont...@bugs.debian.org:
forwarded 571631 https://bugs.internet2.edu/jira/browse/SSPCPP-106
Bug #571631 [libapache2-mod-shib2] libapache2-mod-shib2: shib-keygen generates
world-readable key file
Set Bug forwarded-to-address to
forwarded 571631 https://bugs.internet2.edu/jira/browse/SSPCPP-106
thanks
Dominic Hargreaves d...@earth.li writes:
# ls -l sp*
ls: cannot access sp*: No such file or directory
# shib-keygen
[...]
# ls -l sp*
-rw-r--r-- 1 root root 1164 Feb 26 15:39 sp-cert.pem
-rw-r--r-- 1 root root 1675
Upstream fixed this (with amazing speed -- thanks, Scott!) by using
umask 177. This is stricter than requested, as it affects the
certificate as well, not only the key. Dominic, is this acceptable for
you? (Btw. I recommend using the backported packages, they are more
mature in several respects
On Mon, Mar 01, 2010 at 03:41:51PM +0100, Ferenc Wagner wrote:
Upstream fixed this (with amazing speed -- thanks, Scott!) by using
umask 177. This is stricter than requested, as it affects the
certificate as well, not only the key. Dominic, is this acceptable for
you?
Yes, that's fine.
Dominic Hargreaves d...@earth.li writes:
On Mon, Mar 01, 2010 at 03:41:51PM +0100, Ferenc Wagner wrote:
(Btw. I recommend using the backported packages, they are more
mature in several respects besides the higher version numbers.)
Thanks for the tip; I'll bear it in mind if we encounter a
Package: libapache2-mod-shib2
Version: 2.0.dfsg1-4+lenny2
Severity: critical
Tags: security
Justification: root security hole
When setting up a new SP, I observe the following:
irregular-apocalypse:/etc/shibboleth# ls -l sp*
ls: cannot access sp*: No such file or directory
15 matches
Mail list logo
