init scripts and su
by Russell Coker
For Postgresql there is a minor security issue.
The start scripts do "su - postgres" to launch the daemon, this is to run the
~/.bash_profile file to get settings for the database.
The problem with this is that such scripts are writable by the postgres user
and thus the postgres user can cause their own program to run which can stuff
key-presses into the input buffer of the controlling terminal, this
controlling terminal is in many instances (*) the terminal of an
administrative shell, and commands such as "chmod 666 /etc/shadow" could be
executed.
To solve this I have written a program named init_su to provide the necessary
functionality from su(1) without the terminal issue.
init_su closes all file handles other than 1 and 2 (stdout and stderr). File
handles 1 and 2 are fstat()'d, if they are regular files or pipes then they
are left open (no attack is possible through a file or pipe), otherwise they
are closed and /dev/null is opened instead. /dev/null is opened for file
handle 0 regardless of what it might have pointed to previously. Then
setsid() is called to create a new session for the process (make it a group
leader), this invalidates /dev/tty. Then the uid is changed and the daemon
is started.
I have attached the source code to init_su, please check it out and tell me
what you think.
Also this solves a minor problem with the SE Linux patched su and sudo not
doing quite what we want for daemon startup.
(*) On system boot and shutdown there is no problem. It's when the
administrator uses /etc/init.d/postgresql to start or stop the database that
there is potential for attack.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
19 years, 9 months
Debugging Lockup
by Ivan Gyurdiev
Hi, my system repeatedly locks up. This seems to occur while working
with evolution, but I'm not sure. I use Fedora-development and GNOME.
When it locks up I can move the mouse cursor, but can't click anywhere.
I can't restart X, and can't switch with CTRL-ALT-F*. System responsds
to sysrq. There's no Oops or bug in the log. I have 100k log consisting
of all the kernel messages from boot to reboot, including a sysrq-trace.
I use the binary nvidia driver.
Would this be helpful to anyone to diagnose my problem, and who would
that be? Is this a kernel problem or an X problem, or...
IOW, what can I do to help fix this.
Thanks for your time,
I.G.
19 years, 9 months
Self introduction Hans de Goede
by Hans de Goede
Hi,
First the boring stuff:
J.W.R. de Goede
Rotterdam, The Netherlands
I work as an electronics and computerscience teacher for a dutch
university (www.hhs.nl)
For starters I would like to just build some packages and get them added
to fedora.us:
-I currently have a svgalib (stable version) src rpm sitting on my hd
ready for submission.
-I'm also interested in building a rxvt-unicode rpm and a yodl rpm since
rxvt-unicode needs yodl to generate its manpages, see:
https://bugzilla.fedora.us/show_bug.cgi?id=1901
I haven't got a response from Andreas yett if he is going todo it, if
he's not I very likely will.
-I have plans todo packaging for the following, this might never leave
the plans stadium though:
*emulators for example: xmame, snes9x, genesis-sdl, ....
*I would like to see a free java development environment, like debian
has with free-jdk, so this would mean packaging sablevm, classpath-tools
and a package with wrappers to make it all behave like the real JDK. So
this would be a true virtualmachine based java environment. A bit
quiestion is how this would mix and match with gcc-java.
Besides the packaging I'm interested in:
-making fedora work better on older hardware, without sacreficing
features for new hardware, so intergrating older hardware support into
the core, not creating a seperate distro for older hardware.
-textmode (and xterm and friends) keyboard mapping also know as
home/end/del hel. Just search for bugs submitted by j.w.r.degoede(a)hhs.nl
in RH bugzilla.
-thinclient technologies and diskless clients such as root-over-nfs
-getting rid of small anoyances (the mozzila startup notification in
gnome for example)
Historical qualifications:
-I've started using linux in 1996 and I've been a RedHat user ever
since, currently my home computer doesn't have anything but Linux
installed, and even at work I work mostly under Linux.
-my first programming project was continuing the DOS port of VGB
(gameboy emulator) and backporting the improvements to the unix
original.
-Professionally I've done lotts of embedded projects with Linux,
including Realtime data-aquisition using rtlinux.
-my biggest hobby project sofar has been maintaining and extending
the unix port of mame, xmame. I've stopped doing this due to computer
use related health problems, which I hope to have left behind me now.
-I've written a couple of small howto's on root over NFS and textmode
keybinding hell. Which are now pretty obsolete.
-I've been a RedHat Beta Team member doing testing on the pre public
beta's for RedHat for a couple of years, during that period I've been
offered an QA job at RedHat.
Computer languages and other skills:
-I know my way around computers and esp. Linux pretty well
-I'm not Alan Cox, but I believe I can write pretty decent code.
-I know the following languages:
*C (very well)
*C++ (well)
*Java (well)
*bash (good enough)
*python (done some coding in the past)
*php (done some coding in the past)
Why should you trust me?
-When it comes to trust I know 2 sorts of people, people who start a new
relation ship with a certain amount of trust and adjust this as the
relation continues, and people who start with a certain amount of distrust.
-I'm somebody who likes to start with a certain amount of trust and
start not trusting people if the behave in a way which makes me distrust
them. I hope I will receive the trust I'm willing to show.
GPG KEYID and fingerprint
-Okay this GPG stuff is new to me (remember, I'm the trusting type), so
I hope I get this right:
Regards,
Hans
p.s.
Since I haven't been active in the computerworld for some time I
currently don't have a personal website, can someone help me with some
webspace where I can upload the src.rpm's for the packages I build?
--
EuropeSwPatentFree http://EuropeSwPatentFree.hispalinux.es
19 years, 9 months
Build system missing in action again?
by G.Wolfe Woodbury
I presume the build system is missing in action again since there
haven't been any reports. I hope to see plenty of stuff come through on
monday or tuesday!
Is there someplace that we can look to see the status of the build
system? Perhaps an announcement or something when this happens would be
in order to the devel-list.
--
G.Wolfe Woodbury `- -'
U
The Line Eater is a boojum!
19 years, 9 months
Self introduction Hans de Goede (this time with GPG key)
by Hans de Goede
Hi,
First the boring stuff:
J.W.R. de Goede
Rotterdam, The Netherlands
I work as an electronics and computerscience teacher for a dutch
university (www.hhs.nl)
For starters I would like to just build some packages and get them added
to fedora.us:
-I currently have a svgalib (stable version) src rpm sitting on my hd
ready for submission.
-I'm also interested in building a rxvt-unicode rpm and a yodl rpm since
rxvt-unicode needs yodl to generate its manpages, see:
https://bugzilla.fedora.us/show_bug.cgi?id=1901
I haven't got a response from Andreas yett if he is going todo it, if
he's not I very likely will.
-I have plans todo packaging for the following, this might never leave
the plans stadium though:
*emulators for example: xmame, snes9x, genesis-sdl, ....
*I would like to see a free java development environment, like debian
has with free-jdk, so this would mean packaging sablevm, classpath-tools
and a package with wrappers to make it all behave like the real JDK. So
this would be a true virtualmachine based java environment. A bit
quiestion is how this would mix and match with gcc-java.
Besides the packaging I'm interested in:
-making fedora work better on older hardware, without sacreficing
features for new hardware, so intergrating older hardware support into
the core, not creating a seperate distro for older hardware.
-textmode (and xterm and friends) keyboard mapping also know as
home/end/del hel. Just search for bugs submitted by j.w.r.degoede(a)hhs.nl
in RH bugzilla.
-thinclient technologies and diskless clients such as root-over-nfs
-getting rid of small anoyances (the mozzila startup notification in
gnome for example)
Historical qualifications:
-I've started using linux in 1996 and I've been a RedHat user ever
since, currently my home computer doesn't have anything but Linux
installed, and even at work I work mostly under Linux.
-my first programming project was continuing the DOS port of VGB
(gameboy emulator) and backporting the improvements to the unix
original.
-Professionally I've done lotts of embedded projects with Linux,
including Realtime data-aquisition using rtlinux.
-my biggest hobby project sofar has been maintaining and extending
the unix port of mame, xmame. I've stopped doing this due to computer
use related health problems, which I hope to have left behind me now.
-I've written a couple of small howto's on root over NFS and textmode
keybinding hell. Which are now pretty obsolete.
-I've been a RedHat Beta Team member doing testing on the pre public
beta's for RedHat for a couple of years, during that period I've been
offered an QA job at RedHat.
Computer languages and other skills:
-I know my way around computers and esp. Linux pretty well
-I'm not Alan Cox, but I believe I can write pretty decent code.
-I know the following languages:
*C (very well)
*C++ (well)
*Java (well)
*bash (good enough)
*python (done some coding in the past)
*php (done some coding in the past)
Why should you trust me?
-When it comes to trust I know 2 sorts of people, people who start a new
relation ship with a certain amount of trust and adjust this as the
relation continues, and people who start with a certain amount of distrust.
-I'm somebody who likes to start with a certain amount of trust and
start not trusting people if the behave in a way which makes me distrust
them. I hope I will receive the trust I'm willing to show.
GPG KEYID and fingerprint
-Okay this GPG stuff is new to me (remember, I'm the trusting type), so
I hope I get this right, well I didn't the first try since I hit the
send button too soon, duh:
[hans@shalem hans]$ gpg --fingerprint "Hans de Goede"
gpg: WARNING: using insecure memory!
gpg: please see http://www.gnupg.org/faq.html for more information
pub 1024D/DE6CDFEF 2004-07-25 Hans de Goede <j.w.r.degoede(a)hhs.nl>
Key fingerprint = F99D 63F7 D42E FF2A 6430 63FE E3B2 80DE DE6C DFEF
sub 1024g/D2DC2F2A 2004-07-25
Regards,
Hans
p.s.
Since I haven't been active in the computerworld for some time I
currently don't have a personal website, can someone help me with some
webspace where I can upload the src.rpm's for the packages I build?
--
EuropeSwPatentFree http://EuropeSwPatentFree.hispalinux.es
19 years, 9 months
mdadm raidtools
by Farkas Levente
hi,
is there any progress in the raidtools->mdadm conversion of the boot
process of fedora?
yours.
--
Levente "Si vis pacem para bellum!"
19 years, 9 months
kde3.3beta
by Lars G
any eta when this hits the rawhide channel?
cheers
lars
19 years, 9 months
createrepo/rpm-metadata repository format creator ver 0.3.4
by seth vidal
Hi Everyone,
I'm pleased to announce a release of createrepo that will generate
the xml format for the rpm/package repository metadata. (Metadata is all
the information about a package that the various pkg management tools
(yum, up2date, apt, redcarpet) require to figure out which ones a system
needs to install.)
A number of folks have been discussing and kicking around this format
for a while and I've been slowly writing the code to generate it. After
a number of revisions I think this one is ready for general consumption:
http://linux.duke.edu/metadata/generate/createrepo-0.3.4.tar.gz
http://linux.duke.edu/metadata/generate/createrepo-0.3.4-1.src.rpm
It requires python 2.X, rpm-python and libxml2-python.
You run it like yum-arch:
createrepo /dir/you/want/to/make/into/a/repo
This will create a dir named 'repodata' in that directory. This will
have 4 or 5 files in it, depending on the options you passed to it.
These files are:
primary.xml.gz - this holds the primary metadata for the packages
(names, summary, requires, provides, deps, etc)
filelists.xml.gz - this holds the complete list of files for each
package.
other.xml.gz - this holds all the changelog data and other things that
might come up later
repomd.xml - this file contains all the info pointing to these other
files (along with checksums and timestamps)
Benefits:
- Much smaller than the .hdr files yum currently uses
- consistent to parse in many different programming languages
- extensible for new things that need to show up in there
- will hopefully be supported by all of the pkg management programs
in or around fedora core
- should allow for a whole new set of datamining opportunities such as:
- rss feeds of most recent packages
- fast searching routines for miscellaneous strings
- indexing and comparison of repositories
- whatever else someone can dream up.
In the next few weeks I'll be releasing a version of yum that works with
this format and I'd like to try to make this version ready to go for
Fedora Core 3. However, other applications need to be ported away from
yum's repository format and to this. Rhn-applet needs to be updated to
work with this metadata. I believe up2date is ready to work with it now.
I'm suggesting that this program makes it into fc3 and that rawhide
starts having this format built for it, as well so people can work on
porting applications to this format.
-sv
19 years, 9 months
FC3 Wishlist Item
by Daryll Strauss
A late addition to the FC3 wishlist:
SPF publishing and MTA checks
- |Daryll
19 years, 9 months