Skip to main content

Search

Items tagged with: Linux


 
Zwei aktuelle Linux-Notebooks aus 2018

\#linux #linuxnews #opensource
Zwei aktuelle Linux-Notebooks aus 2018

 

A look at home routers, and a surprising bug in Linux/MIPS


We reviewed 28 popular home routers for basic hardening features. None performed well. Oh, and we found a bug in the Linux/MIPS architecture.
Article word count: 238

HN Discussion: https://news.ycombinator.com/item?id=18688947
Posted by walterbell (karma: 35756)
Post stats: Points: 100 - Comments: 61 - 2018-12-15T16:16:49Z

\#HackerNews #and #bug #home #linux #look #mips #routers #surprising
Article content:

We reviewed 28 popular home routers for basic hardening features. None performed well. Oh, and we found a bug in the Linux/MIPS architecture.

Today weʼre pleased to announce the release of two papers:

In the first paper, we analyze the firmware images of 28 popular home routers, checking for basic code hygiene and software safety features. What we found was disappointing: none of the routers made consistent use of basic [1]software safety features like [2]ASLR, [3]stack guards, and [4]DEP - features which have been standard in desktop environments for over 15 years.

Given the role these devices play in consumersʼ homes, and the ease with which these issues could be resolved, we believe the absence of these features is reckless and negligent. We strongly urge vendors to review their software build practices and adopt practices which ensure these basic security features are present prior to product release.

But thatʼs not all. In the second paper, we describe an unfortunate bug in the Linux/MIPS architecture which we encountered in the course of our reporting on routers. This bug, whose origins date back to 2001, prevents most Linux/MIPS binaries from enjoying the full protections of DEP and ASLR. Given the popularity of Linux/MIPS in embedded devices (such as IoT, consumer and enterprise network equipment, etc), and the enormous diversity of threat models for such devices, we believe this bug represents a significant risk to a large segment of Internet-connected devices.

References

Visible links
1. https://cyber-itl.org/about/methodology/#safety-features
2. https://cyber-itl.org/about/glossary/#a
3. https://cyber-itl.org/about/glossary/#s
4. https://cyber-itl.org/about/glossary/#d

HackerNewsBot debug: Calculated post rank: 87 - Loop: 228 - Rank min: 80 - Author rank: 49

 

A look at home routers, and a surprising bug in Linux/MIPS


We reviewed 28 popular home routers for basic hardening features. None performed well. Oh, and we found a bug in the Linux/MIPS architecture.
Article word count: 238

HN Discussion: https://news.ycombinator.com/item?id=18688947
Posted by walterbell (karma: 35756)
Post stats: Points: 100 - Comments: 61 - 2018-12-15T16:16:49Z

\#HackerNews #and #bug #home #linux #look #mips #routers #surprising
Article content:

We reviewed 28 popular home routers for basic hardening features. None performed well. Oh, and we found a bug in the Linux/MIPS architecture.

Today weʼre pleased to announce the release of two papers:

In the first paper, we analyze the firmware images of 28 popular home routers, checking for basic code hygiene and software safety features. What we found was disappointing: none of the routers made consistent use of basic [1]software safety features like [2]ASLR, [3]stack guards, and [4]DEP - features which have been standard in desktop environments for over 15 years.

Given the role these devices play in consumersʼ homes, and the ease with which these issues could be resolved, we believe the absence of these features is reckless and negligent. We strongly urge vendors to review their software build practices and adopt practices which ensure these basic security features are present prior to product release.

But thatʼs not all. In the second paper, we describe an unfortunate bug in the Linux/MIPS architecture which we encountered in the course of our reporting on routers. This bug, whose origins date back to 2001, prevents most Linux/MIPS binaries from enjoying the full protections of DEP and ASLR. Given the popularity of Linux/MIPS in embedded devices (such as IoT, consumer and enterprise network equipment, etc), and the enormous diversity of threat models for such devices, we believe this bug represents a significant risk to a large segment of Internet-connected devices.

References

Visible links
1. https://cyber-itl.org/about/methodology/#safety-features
2. https://cyber-itl.org/about/glossary/#a
3. https://cyber-itl.org/about/glossary/#s
4. https://cyber-itl.org/about/glossary/#d

HackerNewsBot debug: Calculated post rank: 87 - Loop: 228 - Rank min: 80 - Author rank: 49

 

linux driver backports tip


If you ever have to directly use the backports repo (rather than using a driver backports tarball generated by a vendor or distro) check out the --gitdebug feature
https://backports.wiki.kernel.org/index.php/Documentation/integration#Integrating_a_release

This option is only mentioned in docs for "integration" workflow, but is available for both driver backporting workflows.

Image/Photo

#linux #kernel #drivers #embedded

 

Libcamera: V4L2 successor


Libcamera successor to V4L2 hopes to ease embedded Linux camera headaches

https://youtu.be/GIhV7tiUji0

#embedded #linux #kernel #programming
Libcamera successor to V4L2 hopes to ease embedded Linux camera headaches

 

But is it atomic?


So a few days ago, a colleague asked “Why do we love files on disk?” and in the course of that discussion, I made a comment that, among other things, used the assumption that somebody is updating some file on some Linux system atomically. I wrote:
Let's assume we are using local files, and we do so in a managed, sane way:  

- All these state files are always JSON,  
- there is a JSON schema, so  
-- it is clear which attributes can be there,  
-- must be there, and  
-- what they mean and 
-- what changes to data mean as well.  
- **Files are updated atomically**

And immediately the question came up: “I either misunderstand you or I have a gap in the knowledge. When writes to a file became atomic? They are not in general case.”

There is a Dilbert for that:
https://dilbert.com/strip/1995-06-24

So let’s go back in time, it’s Greybeards time! We’re going to find out where the things you are working with are actually coming from. With sources and references.

The write(2) system call


A write(2) system call is atomic. The size or amount of data written does not matter. How come?
The system call will, before trying to write data to disk, lock the in-memory inode. That is, it will effectively lock the entire file. It then performs the file changes, and only then unlocks. That can take a long, long, long time, depending on the amount of data and the media the file is being stored on.
It means that on a single physical file in Unix, there can be only one write(2) system call active at any point in time.
One exception to this is XFS, but only when a file is opened with O_DIRECT. In this special case, XFS instead locks the byte range in a structure attached to the inode, performs the write and then unlocks. So, in XFS with O_DIRECT, any number of concurrent, non-overlapping write(2) system calls can be active.
The Posix specification requires that write(2) is atomic, it does not require that only one write per file can happen.

That is a horrible thing!


The locking behavior of write(2) is a problem for databases that require many concurrent writes to happen.
Ingres and some other early SQL databases used to solve that problem by avoiding filesystem entirely, they recommended that tablespaces use raw disks. No filesystem, no files, no locks.
Oracle solved the problem by introducing the concept of tablespaces, which are data storage spaces made up by a fleet of files, e.g. one file for each GB of data storage. Tables are assigned tablespaces, not data files directly. Since there is one write lock per inode, concurrent writes to different files in the same tablespace can happen.
Only in 1994, when SGI published XFS, the actual problem was tackled by splitting the lock at the kernel level for buffer cache less writes. XFS also contained many other improvements over the 1984 BSD Fast Filing System that made it superior for concurrent I/O, streaming I/O, very large file systems, and many other modern use-cases. BSD FFS was in turn an improvement over 1974’s original Unix Filesystem.
In Linux terms, the 1974 Unix Filesystem is mirrored by the Minix File system, the 1984 BSD FFS is roughly equivalent to ext2, and XFS was donated and ported to Linux by SGI, bringing that up into the tech level of 1994.
Sun ZFS and Linux Btrfs are from 2004, and are a complete deviation from earlier Unix ideas. They are a different, much longer writeup, which will actually end with the git and the Blockchain.

Source Dive: Why are writes atomic?


“Posix requiring a file write to be atomic” comes from the behavior of the original Version 7 Unix and later systems. In there, we find the write(2) system call, which just calls the rdwr() function.
/\* 
 \* write system call  
 \*/ 
write() 
{  
  rdwr(FWRITE); 
}

You are looking very old K&R style C code here, which predates even ANSI-C and function prototypes, by the way.
So rdwr() a few lines down the function calls plock(), for as long as we are not dealing with a device special file (Here is where the Ingres “use raw devices” idea comes into play), then does the I/O and finally calls prele().
if((ip->i_mode&(IFCHR&IFBLK)) == 0) 
            plock(ip); 
        if(mode == FREAD) 
            readi(ip); 
        else 
            writei(ip); 
        if((ip->i_mode&(IFCHR&IFBLK)) == 0) 
            prele(ip);

plock() is what locks the actual inode and the origin of the observed behavior. It is is a misnomer, it’s not a pipe lock, it’s an inode lock.
/\* 
 \* Lock a pipe. 
 \* If its already locked, 
 \* set the WANT bit and sleep. 
 \*/ 
plock(ip) 
register struct inode \*ip; 
{ 


    while(ip->i_flag&ILOCK) { 
        ip->i_flag |= IWANT; 
        sleep((caddr_t)ip, PINOD); 
    } 
    ip->i_flag |= ILOCK; 
}

See the locking loop here: As as we do not have the lock, indicate desire to get the lock, then sleep on a lock release. When we exit the loop (because the inode is unlocked), lock the inode.
These are simple C Code lines, not special magic macros that translate into special magic TAS machine instructions. That is because the code here is so old that it comes from a world where we have single-die, single-core, single-thread CPUs. If your code is actually running (and this is kernel code!), then you are alone in the entire system. There is nobody else touching these variables as long as you have the CPU.
Under the lock, rdwr() above calls writei(). And writei() has a do loop which uses variables from the u-Area.
do { 
        bn = u.u_offset >> BSHIFT; 
        on = u.u_offset & BMASK; 
        n = min((unsigned)(BSIZE-on), u.u_count); 
        if (type!=IFBLK && type!=IFMPB) { 
            bn = bmap(ip, bn, B_WRITE); 
            if((long)bn<0) 
                return; 
            dev = ip->i_dev; 
        } 
        if(n == BSIZE)  
            bp = getblk(dev, bn); 
        else 
            bp = bread(dev, bn); 
        iomove(bp->b_un.b_addr+on, n, B_WRITE); 
        if(u.u_error != 0) 
            brelse(bp); 
        else 
            bdwrite(bp); 
        if(u.u_offset > ip->i_size && 
           (type==IFDIR || type==IFREG)) 
            ip->i_size = u.u_offset; 
        ip->i_flag |= IUPD|ICHG; 
    } while(u.u_error==0 && u.u_count!=0); 
}

The u-Area of a process at that time was a common data structure that the userland and the kernel used to communicate. Here it is being used to shift syscall parameters into the kernel. The write writes the data at u.u_base in userland into the current inode, at u.u_offset bytes in the file. There are u.u_count many bytes to write.
We convert the u.u_offset into a logical block number (the n-th block of a file), and an offset “on” within the block. We need to call bmap(). This function turns an inode number and block number within the file into a physical block number on a device.
We can then bring the relevant physical block into the buffer cache, using bread(), and then use iomove() to modify and dirty the block. As we brelse() it, it will eventually be written back to disk later.

There is an optimization here:
When the write is a full block, we do not read the block from disk. We just allocate a buffer using getblk(), and fill it. It will overwrite the data on disk completely, there is no old and new data to merge. Disk accesses are slow, in the 1970ies even more so than today, so not reading data that you are going to obliterate completely pays of substantially.
The loop continues as long as there are no errors and still blocks to write.
As we return from writei(), rdrw() resumes and will eventually prele() the inode lock.

How old is this stuff?


This is of course extremely old code, original V7 unix, almost as old as me: git blames places it’s age at 41 years, I was in the third class of a German basic school when this was written.
I chose this implementation, because it is very simple and because it is also what became immortalised in the performance destroying standard which we got to know as Posix File System Semantics.

Homework


You can have fun to find the matching functionality in a modern Linux kernel, threads, multicore, capabilities, namespaces, cgroups and dynamic data structures and all.
Compare code readability and complexity. Discuss. Is this progress? Why do you think so?
You can try to get a copy of “The Design of the Unix Operating System” by Maurice J. Bach. It will take you on a guided tour through the origins of our craft and the legacy we build on. The topics discussed in this note can be found on the pages 101ff, “WRITE” and “FILE AND RECORD LOCKING”.
If you are into operating systems, continue reading after Bach: “The Design and Implementation of the 4.3 BSD Operating System” builds on Bach’s work and showcases the progress and inventions that Kirk McKusick, Sam Leffler et al made after that.
If you are into comparative operating system design, read “Inside Windows NT” by Helen Custer after Bach and Leffler/McKusick, and try to understand the different ideas and world view behind that.

But we don’t use write(2) for atomic file updates!


Well, some of us do, but I agree that it is hard to get right: write(2) and writev(2) are very hard to handle properly in applications, as you need to write everything in a single call.
Most programs use another atomic operation in Unix, the rename(2) system call. You write file.new at your leisure, printf(), chunked writes() and all. When completed, rename file.new to file. This automatically unlinks the old version of file as well.
This is also the recommended approach to atomicity, because unlike write(2) it is stable in the face of the dreaded nightmare file system.
rename(2) was introduced really early in BSD Unix because of specific race problems in the V7 Unix early BSD patched and improved.
Before BSD, we only had link(2) and unlink(2). You can use a combination of these syscalls to implement a rename-like operation, but you need more than one syscall to do that.
In Unix, at the end of a syscall, before return to userland, the scheduler runs (Bach, Chapter 8). That is, at the end of each syscall, a process can be forced to yield the CPU. This is the cause for potential race conditions when not having a rename(2) as a single syscall, and that is why BSD came up with a single syscall for renaming files in the first place.
Renaming files for atomic updates can be taken to an art form: trylooking into the Maildir/ implementations as invented by qmail, and implemented in Dovecot and CyrusAnd that concludes this issue of Our Systems Legacy.

#erklaerbaer #wasmitcomputern #unix #linux #kernel

 

bmaptool for quicker rootfs image flashing


https://github.com/intel/bmap-tools

Conveniently, openembedded has builtin support for bmap

https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#flashing-images-using-bmaptool

Minor note, I prefer wic.gz compressed format to trade off build server cpu for bandwidth downloading the images
IMAGE_FSTYPES += "wic.gz wic.bmap"

#embedded #linux

 
o/ Welcome !!! I uninstalled the G+ app on my mobile not long ago, so I've missed your posts. Hope you start porting your articles here as they're published. There's a nice #Linux community forming here.

 
Steam Link für Raspberry Pi offiziell verfügbar

\#linux #linuxnews #opensource #steam #raspberrypi
Steam Link für Raspberry Pi offiziell verfügbar

 
Hey followers, do you know an easy & universal way how inexperienced users can decode why their #linux #kernel got tainted? Dmesg might not have all the reasons anymore, journalctl might not be in use, and /proc/sys/kernel/tainted is hard to decode if tainted for multiple reasons .

Asking for a friend stupid enough to do regression tracking for the #Linux #kernel now and then in his rare spare time. That's why he is writing a major update for https://www.kernel.org/doc/html/latest/admin-guide/reporting-bugs.html currently. Screenshot from https://www.kernel.org/doc/html/latest/admin-guide/tainted-kernels.html


 
"[…] We are trialing out a new feature that can send you a notification when the patches you send to the #LKML are applied to linux-next or to the mainline git trees. If you are interested in trying it out, here are the details: […]" #linux #kernel kernel.org/get-notificati…


 
What happened in #reproducible-builds last week? See https://reproducible-builds.org/blog/posts/189/ - mostly for #Linux but then we had one friendly #MicroSoft guy join our yearly summit, because their Azure cloud cores already run 50% Linux. And they are using git and open-source these days, too.

And then I wonder if Jim Gettys knows Lynxis, who was working on advancing r-b for openwrt this week.

 
Image/Photo
Linuxnutzer sind Leute, die die Kommentare zu dem Tweet lesen müssen, um zu begreifen, worum es geht.

#Linux #Update #Verwirrung

 
Image/Photo
Linuxnutzer sind Leute, die die Kommentare zu dem Tweet lesen müssen, um zu begreifen, worum es geht.

#Linux #Update #Verwirrung

 

compressing files with hard links


Occasionally things create hard links behind your back...

In this case 'bitbake' build hard-linked a large SD image file into the directory where all output image files get collected. (I forgot to ask for the compressed image format, so was going to just compress it after-the-fact in the image directory).

Linux compression tools (like gzip/bzip2/whatever) are generally smart enough to watch for this situation, so you don't end up losing space by having the original full-size file still lurking somewhere and your newly compressed version of the file. They give you a complaint about "has 1 other link" and bail out by default.

Solution: use 'ls' and 'find' to track down the extra link and kill it, then compress

http://jeremy.zawodny.com/blog/archives/010745.html

#linux

 

 
Wrote up some notes on how I worked around the problem of @dropbox dropping non-ext4 support on #linux .Quick and straightforward. Took a few minutes to setup.
Thanks to @Wimpress for the inspiration.

 
#Linux #Kernel 4.19.9, 4.14.88, 4.9.145, 4.4.167, 3.18.129 are out, bringing the usual pile of fixes and small improvements along with the "you just update" advice. Among the changes in 4.19.9 are a few #Amdgpu patches that improve support for the #Radeon RX 590.


 
Hallo zusammen, ich bin #NeuHier. Ich interessiere mich für #ingress, #linux, #opensouce, #arduino, #diy, #coffee und noch etliches mehr. Mal schauen, wie es sich hier lebt und postet :-)

 
Image/Photo
Hey everyone, I’m #newhere. I’m interested in #analogphotograhy, #australia, #blackandwhite, #fedora, #linux, and #monochrome. This image is "somewhere" Arizona on interstate 10, looking for the next curve in the road.

 
Hey Everyone! Humble Store is doing a #sale on #RocketLeague for just $9.99 - if you aren't aware, I am a pretty big fan of this game so I think it is totally worth this price. :D - https://tuxdigital.com/go/humble-rocket-league-sale (affiliate link) #Linux #LinuxGaming

 
High resolution wheel scrolling on #Linux v4.21: who-t.blogspot.com/2018/12/high-r… Peter Hutterer writes "[…]world wouldn't be complete without fancy hardware […]Logitech high-resolution wheel scrolling […]A few patch revisions later and we now have everything queued up for v4.21. […]"


 

fun with network namespaces


The 'ip' command is your friend

Running a process inside a network namespace

and 'iw' command is also, when working with wireless interfaces

Move wireless connection to other network namespace

For those not yet familiar with the concept of namespaces, LWN is always a good place to start
namespaces overview
network namespaces

Image/Photo

#linux #opensource #networking

 

gcc support for hidden symbols


https://gcc.gnu.org/wiki/Visibility

I learned something in the very last sentence: that 'nm' has builtin demangling support (I used to pipe it through c++filt)

#linux #opensource #programming

 

#NTFS #Symlinks folgen und auch nicht


Hallo, ich bin gerade in folgender Situation und brauche etwas #Hilfe:
Ich möchte gerne einen Laptop neu aufsetzen mit einem aktuellen Linux. Die Festplatte darin war mechanisch gecrasht also habe ich eine andere Festplatte aus einem anderen Laptop eingebaut. Darauf ist ein leidlich funktionierendes Windows installiert.

Nun möchte ich bevor ich die Festplatte formatiere eigentlich ganz gerne das home-Verzeichnis sichern. Dazu habe ich ungefähr das hier gemacht:
cd /media/lubuntu/alteFestplatte/Dokumente\ und\ Einstellungen 
scp -r \* deus@deusComputer:/run/media/deus/Backupfestplatte/Backups/Laptops/Windows/2018-12/

Das schien auch ganz gut zu laufen, bis ich bemerkte, dass 1. der verbrauchte Platz viel größer wurde als ursprünglich veranschlagt (ich hatte sowas wie 60GB gemessen und es waren nun schon 150GB und noch lange nicht fertig) und 2. immer und immer wieder eine relativ große Datei übertragen wurde, aber immer wieder die selbe.

Als ich dann hinterher recherchierte fand ich heraus, dass es eine Softlink-Schleife gibt. …/Dokumente und Einstellungen/All Users/Anwendungsdaten ist nämlich ein Symlink auf …/Users/All Users/Anwendungsdaten und das wiederum ist ein Symlink auf sich selbst bzw. sein Eltern-Verzeichnis.

Und das führte dazu, dass dieses Verzeichnis wieder und wieder und wieder kopiert wurde, eben immer ein paar Dateien bis scp auf diesen Symlink stieß und wieder alles in sich selbst kopierte. Auf meiner Backup-Platte entstand dann eine Verzeichnisstrucktur alà …/All Users/Anwendungsdaten/Anwendungsdaten/Anwendungsdaten/Anwendungsdaten/Application Data/Anwendungsdaten/Anwendungsdaten/Anwendungsdaten/ und jeweils der ganze oder halbe Inhalt in jeder Ebene.

Schon blöd.

Nun kann ich scp (glaube ich) anweisen Symlinks nicht zu folgen, aber normalerweise will ich ihnen ja folgen, jedenfalls wenn sie nicht in eine Schleife führen, vielleicht ist ja irgendwie irgendwo noch eine Datei, die nicht unterhalb von /Users/ liegt, aber die ich dennoch lieber mitkopieren will.

Also meine Ideen sind jetzt: Statt scp benutze ich einfach dd und kopiere die ganze Platte statt nur dem User-Verzeichnis. Dann habe ich zwar etwas "Balast" (nämlich sämtliche Applikationen und ein Windows) aber quasi sauber alles kopiert. Nachteil: So ein image muss man halt mounten (oder so), man kann nicht "einfach so" Dateien daraus öffnen oder einzeln rauskopieren/löschen/verschieben etc. man kann auch nicht ohne weiteres darin suchen etc. es ist halt ein image.

Zweite Idee: Diesen konkreten Link löschen. Vielleicht ist es ja der einzige Widerhaken, der in so eine Schleife führt. Aber irgendwie fühlt es sich "komisch" an die Daten hier zu verändern.
Angenehme Variante davon wäre, dass der Symlink im Grunde bestehen bleibt (am Besten als solcher mitkopiert wird) aber nicht aufgelöst. Vielleicht kann man das l-Bit irgendwie auf 0 setzen?

Aber was mir das liebste wäre, wäre wenn scp sowas wie de-dublication machte, also einfach merkt dass es die Datei, die es da gerade kopiert schon kopiert hat.

So, vielleicht gibt es dafür eine geläufige Lösung, vielleicht hat jemand eine Idee, sagt an! :D

#Frage #Hilfe #Linux #Windows #Backup #deutsch #scp #copy #symlink #ln

 

#NTFS #Symlinks folgen und auch nicht


Hallo, ich bin gerade in folgender Situation und brauche etwas #Hilfe:
Ich möchte gerne einen Laptop neu aufsetzen mit einem aktuellen Linux. Die Festplatte darin war mechanisch gecrasht also habe ich eine andere Festplatte aus einem anderen Laptop eingebaut. Darauf ist ein leidlich funktionierendes Windows installiert.

Nun möchte ich bevor ich die Festplatte formatiere eigentlich ganz gerne das home-Verzeichnis sichern. Dazu habe ich ungefähr das hier gemacht:
cd /media/lubuntu/alteFestplatte/Dokumente\ und\ Einstellungen 
scp -r \* deus@deusComputer:/run/media/deus/Backupfestplatte/Backups/Laptops/Windows/2018-12/

Das schien auch ganz gut zu laufen, bis ich bemerkte, dass 1. der verbrauchte Platz viel größer wurde als ursprünglich veranschlagt (ich hatte sowas wie 60GB gemessen und es waren nun schon 150GB und noch lange nicht fertig) und 2. immer und immer wieder eine relativ große Datei übertragen wurde, aber immer wieder die selbe.

Als ich dann hinterher recherchierte fand ich heraus, dass es eine Softlink-Schleife gibt. …/Dokumente und Einstellungen/All Users/Anwendungsdaten ist nämlich ein Symlink auf …/Users/All Users/Anwendungsdaten und das wiederum ist ein Symlink auf sich selbst bzw. sein Eltern-Verzeichnis.

Und das führte dazu, dass dieses Verzeichnis wieder und wieder und wieder kopiert wurde, eben immer ein paar Dateien bis scp auf diesen Symlink stieß und wieder alles in sich selbst kopierte. Auf meiner Backup-Platte entstand dann eine Verzeichnisstrucktur alà …/All Users/Anwendungsdaten/Anwendungsdaten/Anwendungsdaten/Anwendungsdaten/Application Data/Anwendungsdaten/Anwendungsdaten/Anwendungsdaten/ und jeweils der ganze oder halbe Inhalt in jeder Ebene.

Schon blöd.

Nun kann ich scp (glaube ich) anweisen Symlinks nicht zu folgen, aber normalerweise will ich ihnen ja folgen, jedenfalls wenn sie nicht in eine Schleife führen, vielleicht ist ja irgendwie irgendwo noch eine Datei, die nicht unterhalb von /Users/ liegt, aber die ich dennoch lieber mitkopieren will.

Also meine Ideen sind jetzt: Statt scp benutze ich einfach dd und kopiere die ganze Platte statt nur dem User-Verzeichnis. Dann habe ich zwar etwas "Balast" (nämlich sämtliche Applikationen und ein Windows) aber quasi sauber alles kopiert. Nachteil: So ein image muss man halt mounten (oder so), man kann nicht "einfach so" Dateien daraus öffnen oder einzeln rauskopieren/löschen/verschieben etc. man kann auch nicht ohne weiteres darin suchen etc. es ist halt ein image.

Zweite Idee: Diesen konkreten Link löschen. Vielleicht ist es ja der einzige Widerhaken, der in so eine Schleife führt. Aber irgendwie fühlt es sich "komisch" an die Daten hier zu verändern.
Angenehme Variante davon wäre, dass der Symlink im Grunde bestehen bleibt (am Besten als solcher mitkopiert wird) aber nicht aufgelöst. Vielleicht kann man das l-Bit irgendwie auf 0 setzen?

Aber was mir das liebste wäre, wäre wenn scp sowas wie de-dublication machte, also einfach merkt dass es die Datei, die es da gerade kopiert schon kopiert hat.

So, vielleicht gibt es dafür eine geläufige Lösung, vielleicht hat jemand eine Idee, sagt an! :D

#Frage #Hilfe #Linux #Windows #Backup #deutsch #scp #copy #symlink #ln

 

Debian Security Advisory DSA-4353-1 security@debian.org
https://www.debian.org/security/ Moritz Muehlenhoff
December 10, 2018 https://www.debian.org/security/faq- - - - - -

Package : php7.0
CVE ID : CVE-2018-14851 CVE-2018-14883 CVE-2018-17082
CVE-2018-19518 CVE-2018-19935

Multiple security issues were found in PHP, a widely-used open source
general purpose scripting language: The EXIF module was susceptible to
denial of service/information disclosure when parsing malformed images,
the Apache module allowed cross-site-scripting via the body of a
"Transfer-Encoding: chunked" request and the IMAP extension performed
insufficient input validation which can result in the execution of
arbitrary shell commands in the imap_open() function and denial of
service in the imap_mail() function.

For the stable distribution (stretch), these problems have been fixed in
version 7.0.33-0+deb9u1.

We recommend that you upgrade your php7.0 packages.

For the detailed security status of php7.0 please refer to
its security tracker page at:
https://security-tracker.debian.org/tracker/php7.0

Further information about Debian Security Advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://www.debian.org/security/

Mailing list: debian-security-announce@lists.debian.org

#php #php7 #it-security #linux #debian #IT-Sicherheit #it-security

 
OpenSSH-Backdoors: Sicherheitsforscher entdecken 21 Linux-Malware-Familien #Linux #Malware #OpenSSH

 
G3T 0WNED L1NUX N3RDZ: Community-Webseite Linux.org gekapert #CodeofConduct #DNS #Hackerangriff #Linux #LinuxundOpenSource #Linuxorg #Vandalismus

 
Firefox 64 mit neuem Task-Manager und Multi-Tabs

\#linux #linuxnews #opensource
Firefox 64 mit neuem Task-Manager und Multi-Tabs

 
Image/Photo
Image/Photo
Image/Photo
Image/Photo
Image/Photo
Image/Photo
Image/Photo
Image/Photo
Image/Photo

Popularité des #tag


Voici un petit classement de popularité des #tags pour la période allant du 03/12/2018 à 00:00:00 au 09/12/2018 à 23:59:59 (UTC):

#tags les plus populaires


Voici les #tags qui ont suscité le plus de réactions:

#tags les plus utilisés dans les messages


Voici les #tags qui ont été utilisés le plus souvent dans les messages:

Remarques


Nombre de messages parcourus: 51267

Ce classement n'a rien de scientifique et a été réalisé par un robot d'indexation qui ne recense que les messages publics sur certains pods. La méthodologie utilisée est expliquée (succinctement) ici: https://fc.leemhuis.info/display/ba6d1740c32901363f192a0000053625

#tendance #tags #diaspora #popularité #statistique

 
Image/Photo
Image/Photo
Image/Photo
Image/Photo
Image/Photo
Image/Photo
Image/Photo
Image/Photo
Image/Photo

Popularité des #tag


Voici un petit classement de popularité des #tags pour la période allant du 03/12/2018 à 00:00:00 au 09/12/2018 à 23:59:59 (UTC):

#tags les plus populaires


Voici les #tags qui ont suscité le plus de réactions:

#tags les plus utilisés dans les messages


Voici les #tags qui ont été utilisés le plus souvent dans les messages:

Remarques


Nombre de messages parcourus: 51267

Ce classement n'a rien de scientifique et a été réalisé par un robot d'indexation qui ne recense que les messages publics sur certains pods. La méthodologie utilisée est expliquée (succinctement) ici: https://fc.leemhuis.info/display/ba6d1740c32901363f192a0000053625

#tendance #tags #diaspora #popularité #statistique

 

 
Unbekannter Hacker leitete DNS um und trollte Foren-Besucher, vermutlich aus Abneigung gegen Trans-Entwickler. #CodeofConduct #DNS #Hackerangriff #Linux #LinuxundOpenSource #Linuxorg #Vandalismus

 
Nextcloud 15 goes Social

\#linux #linuxnews #opensource #nextcloud #mastodon
Nextcloud 15 goes Social

 
#Linux 4.20-rc6 is out. lore.kernel.org/lkml/CAHk-=wgH…
"[…] we have at least one more rc to go. […] I still suspect that what I'll do is release 4.20 just before xmas (so with the usual "rc7->final" cadence) […] And of course, if we have something worrisome come up […]"


 
Image/PhotoThorsten 'the Linux kernel logger' Leemhuis(6/6) wrote the following post Sat, 08 Dec 2018 13:31:34 +0100

#Linux #kernel 4.19.8 is out. It fixes the data corruption issue in blk-mq that made the news recently and was alleged to ext4 in the beginning.

Note: The fix applied on Wednesday was basically reverted today and replaced by a better one. For details see git.kernel.org/pub/scm/linux/…



kernel/git/stable/linux.git - Linux kernel stable tree #Linux

 

mutt email tip: mail aliases


* To add new alias, select email in main mail index and hit 'a'
* To view or delete existing aliases, Enter aliases menu via key when starting a new email

#linux #opensource

 
#Linux 4.19.8 with the new fix for the data corruption issue in blk-mq is now available in my #Kernel vanilla repositories for #Fedora 28 and 29: fedoraproject.org/wiki/Kernel_Va…
Side note TWIMC: The current kernel from updates-testing contains a fix, too, but it's the older one.

 
BTW, #Linux 4.14.87 and 4.9.144 are out, too. All those new #Longterm #kernel bring the usual pile of fixes and small improvements, so you must update.

Site node: If you do not know which kernel version line is the best for your machines go and read kroah.com/log/blog/2018/…

 
#Linux #kernel 4.19.8 is out. It fixes the data corruption issue in blk-mq that made the news recently and was alleged to ext4 in the beginning.

Note: The fix applied on Wednesday was basically reverted today and replaced by a better one. For details see git.kernel.org/pub/scm/linux/…


 
Mageia 7 als Beta freigegeben

\#linux #linuxnews #opensource #mageia
Mageia 7 als Beta freigegeben

 
The fix for the data corruption in blk-mq (alleged to #ext4 earlier) was "basically reverted" by a newer fix in #linux mainline; it takes a different angle and fixes a livelock the earlier patch created: "blk-mq: punt failed direct issue to dispatch list" git.kernel.org/torvalds/c/c61…

 
The latest DRM merge in #Linux #kernel mainline (and thus for 4.20) contains a few patches that are supposed to make Radeon RX 590 cards work better. There are also some fixes for Vega20. git.kernel.org/torvalds/c/d38…

 
Ubuntu Touch OTA-6 wird verteilt

\#linux #linuxnews #opensource #ubports #ubuntutouch
Ubuntu Touch OTA-6 wird verteilt

 
#Mesa 18.3 is out. It contains performance improvements and new features in various of its #OpenGL and #Vulkan #3D #Linux drivers; it also brings support for a few new GPUs. All that is especially true for GPUs from #AMD and #Intel

mesa3d.org/relnotes/18.3.…
lists.freedesktop.org/archives/mesa-…