Live data from Hacker News

The trouble with symbolic links

lwn.net

121–126 of 126 posts

Re: The trouble with symbolic links

#121

I was copying a file today and thought: "Why is it duplicating the data? Why does it not just create a new second filename pointer in the filesystem?"

Take a look at the cp man page - https://www.man7.org/linux/man-pages/man1/cp.1.html Look for "reflink" and you get your wish :)

FICLONE is the underlying ioctl:

https://www.man7.org/linux/man-pages/man2/ioctl_ficlone.2.ht...

As of Linux 5.18, it's supported by btrfs, xfs, overlayfs and some networking filesystems.

Re: The trouble with symbolic links

#122
post #99
post #95

Earlier quoted context omitted.

> How is it hopelessly elitist to call out insecure code as being INSECURE!!! If a lot of code, written by a lot of different engineers, all ends up being insecure, it is worth asking, why is code dealing with this particular domain so often insecure? > But why not try to EDUCATE THEM?!? You can do that, and of course we should, but here is the thing about security: The good guys have to write secure code every time,…

People being educated for a specialist job, I wonder how they will cope. Well we hire in enough others for less serious problems, sure why not hire less than competent people to slap a fixed badge on the side of it. If you want this level of abstraction it should be built into the framework or language you're using. I'm not saying go away and rewrite chrome in C you'd be chasing segfaults for 5 years. If you want to…

I think we're arguing the same thing.

Write an abstraction on top of the hard to use API for the majority to use, and people who need to use the low level API directly can learn to do so.

Re: The trouble with symbolic links

#123
post #114

Earlier quoted context omitted.

> Couldn't this pretty easily be solved at the file system level? It will not solve a problem that does not even exist in the first place, but will rather badly break the semantics of the UNIX file system precisely at the file system level. > Just store a back pointer from a file to each of its names. UNIX file systems do not have files in the conventional sense. They have disk block allocations referenced to by an i…

> It is even possible to zero directory entries pointing to an inode. Historically, fsck would link such anonymous inodes into lost+found using their inode number as their name in the lost+found directory, but I admit having no idea whether this still applies to modern journaled file systems.

File system journals have reduced the likelihood of unlinked inodes ending up in /lost+found but have not eliminated it completely. There is still a non-zero chance a journal corruption as well during a unexpected shutdown or complete power loss during the journal update and something turning up after a full fsck run later.

Re: The trouble with symbolic links

#124
post #99

Earlier quoted context omitted.

People being educated for a specialist job, I wonder how they will cope. Well we hire in enough others for less serious problems, sure why not hire less than competent people to slap a fixed badge on the side of it. If you want this level of abstraction it should be built into the framework or language you're using. I'm not saying go away and rewrite chrome in C you'd be chasing segfaults for 5 years. If you want to…

I think we're arguing the same thing. Write an abstraction on top of the hard to use API for the majority to use, and people who need to use the low level API directly can learn to do so.

Strange how we end up here after calling me elitist... Please remember this for next time you interact with someone.

Re: The trouble with symbolic links

#125
post #124

Earlier quoted context omitted.

I think we're arguing the same thing. Write an abstraction on top of the hard to use API for the majority to use, and people who need to use the low level API directly can learn to do so.

Strange how we end up here after calling me elitist... Please remember this for next time you interact with someone.

You started off by insulting people who write code that has security holes. I started off by saying the solution is to make APIs that make writing security holes harder.

You characterized people who write code with security holes as "stupid/lazy", that is elitism.

About ~10 years ago, a lot of databases used to ship with no PW on by default. This lead to a lot of information disclosures as people new to the cloud based world setup a DB and all of a sudden it was world readable with no authentication needed.

When this happened, a bunch of experienced DBAs started saying the problem was mass incompetence on the part of these "young developers who think they know how to be a DBA." Their proposed solution was for companies to start hiring "real DBAs".

The actual solution was to have databases not allow exposure over a public IP unless a password is set, which is now the default on the vast majority of databases, and when it isn't, there are giant warning banners that flash everywhere alerting developers to the giant security hole they are about to deploy.

I'm not saying elitism is always bad. Those DBAs who understand exactly how query optimizers work and exactly how databases store everything under the hood are needed, just as the developers who know the detailed ins and outs and proper usage of low level operating system APIs are needed.

But if a lot of otherwise capable developers keep making the same mistake using some tool or API or cloud service, instead of trying to assign blame to individuals for being stupid or lazy, we as an industry should instead ask ourselves why so many people are having the exact same problem.

I'm elitist about plenty of things, and it took me time to realize that just because I know the "best" or "correct" way for something to be done, doesn't mean that everyone else needs to do that thing in the "best" way.

Anything in this world meant for usage by a large number of people, a product, API, flat packed furniture, setting up a printer, needs to cater to the needs of the job that people want to get done. Saying people are "doing it wrong", well, at best that approach gets companies put out of business (see: Everyone selling smartphones who wasn't Apple/Google), and at worst the harm can be magnified many fold.

Re: The trouble with symbolic links

#126
post #5

Interestingly, Windows actually did exactly what's proposed at the end when MS added them in Vista. To minimize the security issues with symlinks, you had to elevate to admin to create them. It was only during the life of Windows 10 that they even added the option to not have to elevate to create them. It was done specifically because symlinks are often shared across systems since they end up in places like git repos…

> It was only during the life of Windows 10 that they even added the option to not have to elevate to create them Nah it was available from the start in local security policy settings. https://docs.microsoft.com/en-us/previous-versions/windows/i...

Thanks for the correction. I actually think I did use this option way back, but just completely forgot about it.
Post reply on HN