F18 defect in playing CDs.
by Aaron Konstam
Previously in earlier versions of Fedora under GNOME when you put in a
CD it played the CD with whatever program you indicated should be used
automatically. Now that I have installed F18 on a second machine I found
the same behavior as on the first machine. The CD is not played
automatically but has to be played manually.
Why is this or what am I doing wrong?
--
Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam(a)sbcglobal.net
11 years, 2 months
undo rm -rf *
by Celik
Hi,
Had a logic error in my bash script and did "rm -rf *" on my current
working directory. Any tips for undoing such an error?
Regards,
C
11 years, 2 months
Re: undo rm -rf * (Patrick O'Callaghan)
by Rick Walker
> > > pseudo-rm is going to fail, either because the implementer didn't
> > > handle some corner case correctly, or because you typed rm instead
> > > of nrm, or because a file was removed by a program without anyone
> > > typing anything, and the only solution is to have a backup. So if
> > > you're going to have a backup anyway, what's the point?
Sometimes multiple safety nets are better than just one.
I haven't found any failures in more than 20 years of daily
linux/hpux nrm usage. Of course, YMMV.
I have the following alias in both root's and my .bashrc
alias rm='/bin/nrm
I have to type "\rm" when I want to really delete things (like the .gone
directory itself). This is handy because I can use a regular expression
to delete files, and then take a look at the .gone directory to make
sure I really deleted just the files I wanted to. Then if I need
the disk space I can delete the directory with "\rm -r .gone".
Most of the time, I let the files get deleted by the normal
cleanup cron job.
I've used nrm (http://omnisterra.com/walker/linux/nrm.html) since around
1987 and have found the current version to handle all my corner cases
properly (even return codes). The initial versions did have some funny
corner cases with deleting targets of symlinks, and some speed problems
in deleting huge numbers of files, but those problems have been fixed a
long time ago.
Heck, it's open-source. Any corner case
that didn't work got fixed by looking at the equivalent code in gnu-rm
or hpus-rm to see how it should be done.
> > Lets say we did a daily backup at 9:00am and deleted some files by error at
> > 5:00 pm. Then what???
Just do "ls .gone" and "cp .gone/critical_file ."
> If you're worried about that, then backup on an hourly basis, or even
> more frequently. Modern backup solutions such as rsnapshot or obnam do
> this incrementally and at very low cost. Then you can only lose a
> maximum of an hour's work.
"nrm -s" keeps a fine-grained horde of every deleted file - even
multiple deletes of the same file! The strategy works so well, that I'd
seriously propose the .gone strategy as a kernel option. Then all
"unlink" calls would use the same sequencing system even if the file
was removed by a program without "anyone typing anything".
Backups are a highly recommended and mostly orthogonal safety
net.
The nrm approach also diverts lots of support requests from the
department backup guru, and lets most users fix their own problems
without any need for help.
kind regards,
--
Rick Walker
11 years, 2 months
Re: Expanding the list of "Hardened Packages"
by Reindl Harald
Am 29.03.2013 23:07, schrieb John Reiser:
> On 03/29/2013, Reindl Harald wrote:
>
>>> -fPIE code is larger and takes longer to execute. The cost varies from
>>> minimal (< 2%) in many cases to 10% or more for "non-dynamic" arrays on i686
>>
>> i686 becomes more or less dead
>>
>> there could be made a difference in SPEC-files to in border
>> cases only harden the x86_64 binaries because in context
>> of servers i686 is already dead except legacy systems which
>> are not relevant for recent fedora versions
>
> The usage of i686 user-mode software is *INCREASING*, especially on x86_64 machines
> which run a 64-bit kernel. The same amount of physical RAM can support several
> percent more simultaneous 32-bit user-mode processes before paging. 64-bit .text,
> pointers, and longs are larger. Only a few applications need a 64-bit address space.
> It will be many years before i686 user mode dies.
the machines below are all installed 2008
this is five years ago
the machines did load-peaks only a few people saw in real-life
well many times and i rebuild ANY relevant package with PIE
last year we bought a DL380 with 2 x Xeon E5-2640 and 92 GB RAM
plus a additional CPU and 60 GB RAM for the other host by a
price of around 8000 € and you will explain me that hacks like
PAE are growing?
[root@buildserver:~]$ distribute-command.sh "rpm -qa | grep x86_64 | wc -l; rpm -qa | grep i686 | wc -l"
--------------------------------------------------------------------------
896
0
411
0
335
0
279
0
283
0
368
0
217
0
218
0
344
0
342
0
237
0
239
0
399
0
335
0
344
0
895
0
279
0
283
0
368
0
>> * please do not argue with "but you need this and this AND this"
>> the expierience of the last years shows how creative attackers
>> are acting with RANDOM input data
>
> I'm arguing the total expected benefit (integral over time of estimated
> exposure times expected prevented loss) versus actual cost (more machines,
> RAM, heat, [avoided] latency). I'm not convinced that PIE+RELRO
> is worth it except for a process with elevated privilege or extended lifetime.
>
> Please cite some documented cases where PIE and/or RELRO prevented or delayed
> an actual loss, or signaled with sufficient warning to be useful. Meanwhile
> I'm spending more each month to consume more resources because of PIE+RELRO
this is a naive approach
you CAN NOT measure a failed code-execution
you can only measure a successful intrusion and that only if you
take notice that it happened - looking in my firewall logs only
a few people out there are in the position having the knowledge
to notice intrusions on their machines
11 years, 2 months
Re: Expanding the list of "Hardened Packages"
by Reindl Harald
CC to the users list because this is a interesting topic at all
Am 29.03.2013 18:48, schrieb John Reiser:
>> Thinking from a security perspective, I find "Hardening flags can only
>> be disabled for other packages at the maintainer's discretion provided
>> enough justification is given to FESCo" to be more appropriate.
>
> -fPIE code is larger and takes longer to execute. The cost varies from
> minimal (< 2%) in many cases to 10% or more for "non-dynamic" arrays on i686
i686 becomes more or less dead
there could be made a difference in SPEC-files to in border
cases only harden the x86_64 binaries because in context
of servers i686 is already dead except legacy systems which
are not relevant for recent fedora versions
> -fPIE for Thumb mode on ARM is particularly painful.
>
> RELRO can cost one extra page of physical RAM per process because the placement
> of the RELRO region tends to increase fragmentation and decrease sharability.
>
> I suggest that any requirement for increased hardening be restricted to only
> those programs which execute with elevated privileges. The package maintainer
> should retain primary discretion for anything which executes with "ordinary"
> user privileges
wrong point of view
the question is what data a binary is supposed to get as input
the "ordinary users privileges" doe snot help you much in case
of local root exploits and keep also in mind that in context of
network-serrvices or software which typically communicates
with foreign network-services a "local exploit" very fast
becomes a "remote exploit"
example:
* foreign user uploads images / pdf-files to a web-form
* on the server side imagemagick or poppler libs proceed the data
* if these libraries are vulerable by the input file and at the
same moment a local root exploit is not fixed on the machine
you are very soon in the situation of a root-exploit
* please do not argue with "but you need this and this AND this"
the expierience of the last years shows how creative attackers
are acting with RANDOM input data
yes performance matters
yes i am the first who likes optimized binaries
but NOT for the price of weaker security
11 years, 2 months
yum upgrade
by Richard Vickery
Sorry for the double-posting:
I've been to the fedora-upgrade (wiki) sites and got confused. Can someone
give me a shortened, simplistic version for stupid people (ie: myself) of
how to use the yum-upgrade command?
Sincerely,
Richard
11 years, 2 months
Anyone that can Recommend a Laser Printer
by Mickey
I'm looking to buy a Laser Printer that will work great in Fedora, in
the price range of $200 - $400 price range. any recommendations ?
Don't want any more Samsung printers they don't care about Linux support.
11 years, 2 months
