Dot Dot Considered Harmful

https://fuchsia.googlesource.com/docs/+/HEAD/the-book/dotdot.md

by rohan1024 • 8 years ago

345 173 8 years ago

fuchsia.googlesource.com

IridiumFX• 8 years ago

It’s a thing born in google. It shows. The reasoning behind problems and solutions is so abstract that makes for a beautiful paper or a nightmarish reality. In the ‘80s there was a little known machine, called the Commodore Amiga. Paths were addressed by a volume:folder/file schema. Apps had logical volumes too (progdir:) and the os injected others (env: temp: fonts: ..) guess what? Just use that schema and control what an app can access or not. If you don’t give me a volume for a disk, I cannot make my way to it if it’s not collated into a mountpoint thing

wmf• 8 years ago

This particular idea wasn't born in Google; it traces back through previous secure OSes like EROS and KeyKOS maybe with a dash of Plan 9 thrown in.

ratmice• 8 years ago

NLTSS as well

mixmastamyk5• 8 years ago

I wouldn't say the Amiga was little known, though it did lose the war over the desktop.

I like that syntax by the way, kind of like drive letters but much more descriptive and not limited to A-Z. Netware also used it for full path specs.

ycmbntrthrwaway• 8 years ago

What you describe is called "namespaces". Plan 9 and Linux have them already.

yiyus2• 8 years ago

In Plan 9, special measures were taken to get dot dot right, not so much because of private namespaces but because of bind.

http://doc.cat-v.org/plan_9/4th_edition/papers/lexnames

GauntletWizard• 8 years ago

Docker "Volumes" are headed that way... but aren't quite there yet. There's a lot of finer detail to hash out first, though.

trasz2• 8 years ago

I believe it comes from DIGITAL systems, eg VMS.

koblas3• 8 years ago

It's interesting to think that the goal of '..' was for navigation around the command line shell. Which is a tool that 95% of people developing software never really use, or use as a necessity (type one command and leave). It's really an interesting thought piece to consider that the idea of the '..' directory is as legacy as the headphone jack.

mixmastamyk5• 8 years ago

Developers who don't use a command-line shell, at least some of the time, aren't much of a developer.

rjplatte3• 8 years ago

I think he means that people who use IDEs don't use shell file navigation as often.

overgard• 8 years ago

That’s pretty harsh, it really depends on the platform/project. If you’re doing a lot of development on windows for example you’re probably not doing a ton on the command line (not everyone is on a Mac doing web or mobile). I know doing Unity3d game development in windows 10 the only time I really use the command line is when I need to do something in git that sourcetree can’t do. And I know the command line plenty well! There’s just no huge reason for this current project.

Plus some languages sort of have their own customs. Like if you were doing Smalltalk a lot of things you’d use a command line for in web development or mobile dev you’d use a workspace in the IDE instead. And then you have Lisp, where people used to joke that Emacs had become its own OS essentially.

Phrodo_00• 8 years ago

the idea of the '..' directory is as legacy as the headphone jack

so... not at all?

I like this approach from Fucshia, Makes me remember dumb sploits in php code. You can take the commandline from my cold, dead hands.

paulddraper3• 8 years ago

Yeah, that analogy was bizarre.

Meph5042• 8 years ago

I think you vastly under estimate the usage of command lines by developers. Not to mention opts and admins.

I don't think there is a week that has passed in the last 10 years that I haven't used the command line for something.

To the point of the article, it sounds like the client will handle the work the server once did in parsing the navigation and path commands.

Though the lack of symlinks sounds like it would be the a more painful loss than ".."

Both of these would likely require many *nix utils to be changed to be compatible.

JoeAltmaier• 8 years ago

I'm not so sure. I can go a week and not use one. And lately its not been a win - the shell didn't get me anything.

ashelmire• 8 years ago

A week! If I go an hour without using the command line, then it's because I'm not actually coding.

ams6110• 8 years ago

Other than the web browser, I can go weeks without accessing any other GUI on my desktop.

parliament32• 8 years ago

More like 15 minutes, but I get your point.

It's possible parent is some super-junior developer doing compartmentalized tasks and never leaving the IDE, but for anything past that avoiding the CLI and remaining productive is basically impossible.

koblas3• 8 years ago

After developing on unix variants for over 20 years, I can say that most people developing software do not use the command line. I see this every day... Even skilled developers run from command line git and into a GUI tool, instead of really understanding the tooling they're using.

pbhjpbhj• 8 years ago

`history` tells me I used 17 commands this evening, I'm a plain old user in relative terms here [my day job only requires computers for accessing social media].

yashap• 8 years ago

Uh what? That’s maybe true with extremely junior devs, or in Windows shops, but most devs I know use the command line very heavily.

androidgirl• 8 years ago

I cant imagine development without my shell at this point.

Even if I didn't use vim+tmux, so much other "stuff" needs the terminal. Compiling, profiling, testing, searching, moving files around, ssh/rsync and so on.

Sure, IDEs have most of this stuff, but they're not always as user friendly as cli tools, at least once you're acquainted with the later.

the_jeremy• 8 years ago

I've only worked at 2 companies, but every developer I've worked with at both used the shell at least weekly.

settler4• 8 years ago

Maybe if your experience using a shell is only Window's CMD. I live in the shell. My Linux machines are configured to automatically open a terminal upon login and the first thing I do when I get a new Windows installation is getting bash working on it even if it's not for development.

dooglius• 8 years ago

This should probably point at the upstream page by the fuchsia project (https://fuchsia.googlesource.com/docs/+/HEAD/the-book/dotdot...) rather than a mirror source repo

rjplatte3• 8 years ago

Upstream

Ironic

malkia• 8 years ago

Rusty... trying to picturesque it...

sctb• 8 years ago

Sure thing, we've updated the link from https://github.com/fuchsia-mirror/docs/blob/master/the-book/....

rohan10242• 8 years ago

I was wondering who updated it. Thanks.

romeisendcoming• 8 years ago

Lost me at 'story' 5 times in a paragraph. Get rid of the story and get on with the real relation.

starclaps• 8 years ago

That’s why tools like gosec complain when user input is used to access files - specifically because ‚..‘ allows one to „escape“.

Gosec: https://github.com/securego/gosec

akerl_• 8 years ago

Given that they’re still resolving “..”, they’re just resolving it in code client-side before requesting the content, they really haven’t gotten rid of “..”: they’ve implemented a path sanitization library, similarly to how many other frameworks (notably those designed to serve files over the web) behave.

ivanbakel• 8 years ago

That is getting rid of ".." - the client-side version is fundamentally different in behaviour, since it can't be resolved without prior knowledge of the filesystem. ".." isn't being sanitised from user paths, it's being translated, because there is no equivalent concept in the file server.

itp• 8 years ago

No, it's deeper than that. They are describing the capabilities of a process handed a file descriptor, which means it does not have a path at all. There's no way to resolve '..' relative to no path.

Compare that to a POSIX system where a directory has an actual child which is a reference to the directory's parent whose name is always '..'.

The talk about resolving '..' is merely a demonstration that the behavior of "cd .." can be supported/emulated in a context where you have both an open directory and corresponding path, without requiring that '..' literally exist.

loeg8• 8 years ago

To add to that, as the document writes in the very first section, it can sort of be thought of as a chroot. You can't .. out of a chroot; there is no "..". (Yeah, it's not exactly a chroot; that's well covered in the document.)

delinka• 8 years ago

If a handle is provided to a directory, it should imply access to resources within that directory (and additionally, their subdirectories).

Maybe within Fuschia, but not in my UNIXy systems. All users on a system need r-x on /Users, but that doesn't give them r-x on every user's home directory located as a subdirectoy of /Users - a handle acquired by bob to /Users does not imply access to /Users/delinka.

Further, if your process is treating '..' as a subdirectory, you're doing it wrong. Paths must be normalized (e.g. ~ expanded, . and .. resolved) before requesting a handle via absolute path.

Lastly, this document reads as if knowing a full path grants access to that path and its subdirectories. If that's the case ... oy.

rzzzt• 8 years ago

NTFS has a toggle bit for access inheritance: http://www.ntfs.com/ntfs-permissions-explicit.htm

trasz2• 8 years ago

Not just NTFS; it’s a common feature in systems that support NFSv4 ACLs, like Solaris or FreeBSD.

ninkendo• 8 years ago

The answer to that for a capability-based system would be to not grant a process access to /Users, but instead give it an opaque handle that grants access to /Users/delinka. It's definitely not how unix systems work (where you need read access to all of the parents to access a child directory), but in a capability-based system it makes sense IMO.

cyphar9• 8 years ago

You don't need read access to all parents (on Linux and BSDs at least) -- a privileged can pass a dirfd to a less privileged process and that process can access paths under that dirfd without any permission checks being done for parent directories of the dirfd.

daurnimator• 8 years ago

You don't need read access, only execute access.

wahern2• 8 years ago

Further, if your process is treating '..' as a subdirectory, you're doing it wrong. Paths must be normalized (e.g. ~ expanded, . and .. resolved) before requesting a handle via absolute path.

".." is required for atomic traversal (similar to symlinks), which is important in some situations, such as making sure a file tree you've descended isn't removed out from under you in a way that breaks your state. (The directory itself can be moved while you hold the handle, but the important thing is that being able to rely on ".." permits certain algorithms that are safer and more consistent.) Canonicalizing paths introduces race conditions between canonicalization and actual access, which is why this is performed in the kernel.

Canonicalizing paths makes sense if you're accepting paths from untrusted sources and you cannot make use of POSIX openat() + extensions like O_BENEATH. HTTP GET requests are supposed to be idempotent, anyhow, so there shouldn't exist any sort of race condition as a conceptual matter.

But in regular software, it's better to just pass paths as-is. The shell performs "~" expansion, but it doesn't resolve "." or "..". And the shell performs other expansions, like file globbing, for which there's rarely any reason to implement in regular software. Supporting "~" expansion but not file globbing is inconsistent; if you're not the shell, don't implement shell-like features as it just creates confusion and unnecessary complexity.

Calling ".." a holdout from POSIX is misleading. The semantics exist for legitimate and even security-relevant reasons, albeit not necessarily reasons that an embedded smartphone OS may care about. What POSIX lacks is O_BENEATH (from Capsicum) or a similar flag for tagging a directory descriptor to prevent relative paths or otherwise ascending the tree. Capsicum extensions make POSIX perfectly capable of implementing strict capability semantics, and they do so by extending semantics in a manner consistent with POSIX. POSIX isn't inherently broken in this regard, it's just perhaps too feature rich for some use cases and not feature rich enough for others.

There's no end of complaints about POSIX--either it's too complex or too simple. The fact is, no single specification will ever please anybody, so griping about how POSIX is broken is not only pointless but belies a failure to appreciate the underling issues. The alternative to POSIX is basically nothing. Standardizing on Linux is, at best, a lateral move. Adding optional components to specifications has proven the worse of all worlds, and like most other standards POSIX has been slowly removing some optional components altogether while making others mandatory.

cyphar9• 8 years ago

As a complete aside, I'm currently working on a patchset to add O_BENEATH (and some other path resolution restriction flags) to Linux.

https://lore.kernel.org/patchwork/cover/1011459/

ken2• 8 years ago

Further, if your process is treating '..' as a subdirectory, you're doing it wrong.

That's the point they make. And in Unix, it's really easy to do it the "wrong" way (like, "type 3 characters" easy), so lots of people do.

Back before protected memory was common on PCs, some people said "If you're chasing pointers without being sure that it points to a valid address, you're doing it wrong". Well, perhaps so, but in practice lots of programs were doing it wrong, and it was the users who suffered.

Capabilities sound to me a bit like protected memory for persistent storage. It'll be a little inconvenient for a little while, and eventually we'll wonder how we ever lived without it.

wahern2• 8 years ago

"If you're chasing pointers without being sure that it points to a valid address, you're doing it wrong". Well, perhaps so, but in practice lots of programs were doing it wrong, and it was the users who suffered.

Except ".." also is a solution to permitting you to traverse a directory tree without accidentally chasing an invalid pointer; no bug in your program nor any external application can ever make ".." invalid. ".." is equivalent to a back pointer in a linked list or tree structure. Imagine you have a handle to /foo/bar/baz and want to ascend to baz's parent. Between acquiring the handle to /foo/bar/baz and attempting to ascend to the parent, "baz" could have been moved and "/foo/bar" may not exist. Without ".." all of a sudden you're orphaned and your application is stuck in an inconsistent state. Maybe the best solution is to just panic, but that's like saying that all applications should be prepared for any pointer access to segfault at at any moment. That's one solution, and it's actually how some smartphone application environments work. Another solution is guaranteeing the condition can't happen, period. Which is preferable depends on your use cases and which side of an interface you'd prefer to place the burden. For pointers it's fairly obvious which provides the most preferable semantics for maximum safety (or it was until the smartphone and cloud paradigms), but for file systems the answer is less obvious. In Unix when ascending directory trees the scenario of a valid pointer becoming invalid is impossible such that there's always a valid path to the root of the tree (even if the depth can change; you just stop when opening ".." simply reopens the same directory), but for descent there remains the race between readdir + open (as opposed to readdir atomically returning file handles).

These particular semantics were clearly purposeful, not an accident. The former was thought useful, the latter an acceptable simplification. It's why in Unix you can't delete a populated directory in or when a process holds an open reference (unlike other file types), and why you can't hardlink directories.

blablabla123• 8 years ago

> Further, if your process is treating '..' as a subdirectory, you're doing it wrong.
That's the point they make. And in Unix, it's really easy to do it the "wrong" way (like, "type 3 characters" easy), so lots of people do.

The OP is writing about iterating subdirectories and accidentally treating ".." as such, if you use certain low level functions - which is kind of bad practice in most cases anyway.

That's the point they make. And in Unix, it's really easy to do it the "wrong" way (like, "type 3 characters" easy), so lots of people do.

Yeah, pointing to a wrong directory can lead to unexpected results. On the other hand, if this becomes a security issue, then maybe the process should have properly restricted rights as pointed out elsewhere already.

Talking about "..", one could BTW extend the discussion to mixing Filename characters with path separator characters in the same string. ;)

Ajedi32• 8 years ago

Sure, you can do it that way; but now that process being run by bob has full access to everything owned by bob (including, for example, `/Users/bob/.ssh/id_rsa`).

Fuchsia considers that level of access to be unacceptably broad for most applications, which is why it uses a capability-based permissions model instead of a user-based one.

noja• 8 years ago

It does on Ubuntu. /home/* is readable and executable to everyone.

caymanjim• 8 years ago

Ubuntu, with default configuration, does create new user directories as globally-readable, but that's just a poor security decision on their part. There's nothing special about /home itself; it's just the default behavior of adduser. And the permissions on /home have no effect on what the permissions are on new subdirectories created when a user is added.

cryptonector2• 8 years ago

Indeed, this ship has sailed. And if .. did not exist then chdir(2) would be the same as chroot(2) unless knowing an absolute path was enough to allow you to access it (assuming --x permissions on the path's dirname's directory components) then, yeah, you wouldn't gain that much as many paths can be guessed.

There just isn't a short-cut for making sandboxes trivial to setup.

I really wish that Solaris/Illumos Zones were standard on Linux. You could have really light-weight containers as anonymous/ephemeral zones whose "init" is the program you want to sandbox, and more heavy-duty guest-like containers as Zones already is.

The difference between Zones (or BSD jails) and Linux containers is that with Zones (jails) you have to explicitly decide what to share to the zone, while with clone(2) you have to be explicit about all the things you DON'T want to share with the container. I.e., Zones requires white-listing while containers requires black-listing, and we all know that black-listing doesn't work as a security device. Granted, the kernel developers could have forgotten to virtualize something important, but when they fix that you don't have to modify and rebuild the zone/jail launcher.

kiriakasis5• 8 years ago

unless knowing an absolute path was enough to allow you to access it

If understand correctly in fuchsia "absolute path" is always relative to a filesystem handle so knowing it and being able to use it are pretty similar

loeg8• 8 years ago

I think you're confusing namespace and unix file permissions.

You can think of capability-restricted directory descriptors as (sort of) individual-fd chroots. File permissions still apply inside a chroot. But the namespace of anything outside the chroot is totally inaccessible.

xg152• 8 years ago

Lastly, this document reads as if knowing a full path grants access to that path and its subdirectories. If that's the case ... oy.

Well, they speak of the path as a "resource provided to a subprocess". In that context, it sounds more like a handle/file descriptor that the child process can pass to some "read", "write" or "get handles of children" syscalls - and that happens to correspond to the file object at /home/bob/foo.

If so, it wouldn't imply that knowing (or guessing) the string "/home/bob/foo" would automatically give you access to the handle.

That's just my reading of our though, no idea of that is what they actually do.

xg152• 8 years ago

* our -> it

userbinator• 8 years ago

Lastly, this document reads as if knowing a full path grants access to that path and its subdirectories. If that's the case ... oy.

Indeed. When I read...

As a consequence, this implies that a handle to a directory can be upgraded arbitrarily to access the entire filesystem.

...I was wondering whether the author even knows what filesystem permissions are and how they work. I say let the filesystem handle resolving relative paths; and let the permissions system handle the check on whether one is allowed to access the referenced object.

ithkuil• 8 years ago

User centric permissions are too broad. Classic example: you might not want your browser to ever access your own ssh private keys

The topic here is to let a user start a process and pass a restricted view of the file system to that process which in turn can spawn child processes to which it could restrict access even further. In order to make it possible to do useful work it's sometimes necessary to also pass around handles/filedescriptors between processes (possibly within different sandboxes) and it's a good idea that the rules governing the view narrowing are not broken.

monocasa2• 8 years ago

this is an essential idea encompassing microkernels, and other “capability-based” systems

Tiny nit, but microkernels don't imply a capability based security model. For instance Mach, QNX, Redox, etc. aren't capability based.

It's a very good idea for your microkernel to be capability based because it cuts a lot of validation out of the critical path for IPC, but it's by no means a requirement.

comex• 8 years ago

Mach is capability based. (Mach ports are capabilities.)

monocasa2• 8 years ago

You're totally right of course.

I was falsely under the impression that the Mach port table only had a single global namespace.

saagarjha• 8 years ago

at the time of writing, symbolic links do not exist on Fuchsia

Is this for technical reasons, or similar philosophical ones because symbolic links also allow for escaping from “jails”?

loeg8• 8 years ago

I think "at the time of writing" implies they're still under consideration, rather than outright rejected due to philosophical differences.

jepler• 8 years ago

Their whole "scheme", where ".." can be dealt with as a canonicalizing step BEFORE submitting the path to the OS for actual opening, seems to require refinement when symlinks are involved.

Take a perfectly spherical unix:

    $ mkdir /tmp/hn
    $ cd /tmp/hn
    $ ln -s . foo; mkdir bar; touch baz
    $ ls -l bar/../baz foo/baz foo/../baz
    ls: cannot access 'foo/../baz': No such file or directory
    -rw-r--r-- 1 jepler jepler 0 Nov 28 18:21 bar/../baz
    -rw-r--r-- 1 jepler jepler 0 Nov 28 18:21 foo/baz

Fuscsia-with-symlinks would have some extra hoops to jump through to make rewriting act like POSIX in the case that /tmp/hn is not escaped, which surely you'd want if you went ahead and introduced symlinks.

Dylan16807• 8 years ago

which surely you'd want

Nope. I don't want that at all. There's a reason that by default cd goes out of its way to make .. ignore the parent of a symlink.

cyphar9• 8 years ago

It should be noted that this is not without precedent. Plan9 doesn't have symlinks for example, everything is done using binds. You would be surprised how many complications come up when you add symlinks to path resolution code.

yiyus2• 8 years ago

theoh2• 8 years ago

This paper, depending on how you look at it, either justifies the existence of dot dot, or makes it seem like a wart. IMO dot dot is too well-established and essentially sensible (in a minimal UNIX fashion) for it to be removed on a whim. Consider the approach taken by https://man.openbsd.org/unveil.2: if you try to access a file you aren't explicitly allowed to, you get EACCESS or ENOENT. I'm not an expert, and the possibility of errors obviously requires applications to tread more carefully than they might have previously, but it seems like a clean solution.

kiriakasis5• 8 years ago

removed on a whim

They changed the whole concept of having one single root. As I understand the plan is to use many fragmented and independent filesystem handles that can optionally mounted together.

So the restriction is more about non being able to access a folder if you don't have access to an appropriate handle.

Paths like folder1/folder2/../folder2/file are still perfectly fine.

mattigames2• 8 years ago

For irony sake one may link this file as

    https://github.com/fuchsia-mirror/docs/blob/master/the-book/../../master/the-book/dotdot.md

Someone1234• 8 years ago

Not as ironic as you'd think considering the article specifically talks about support for .. in userland tooling and uses CWD as an example.

kiriakasis5• 8 years ago

well actually the article complains about stuff like

https://github.com/fuchsia-mirror/../internal-page/secret-re...

which quite more serious

Retr0spectrum• 8 years ago

Nope, that actually 404's. It may appear to work, because most browsers will apply some equivalent to the `__fdio_cleanpath()` function mentioned in the article, resolving the traversal locally.

You can verify this as follows:

    curl -I --path-as-is 'https://github.com/fuchsia-mirror/docs/blob/master/the-book/../../master/the-book/dotdot.md'

mattigames2• 8 years ago

if most browsers apply it... doesn't that means it works? Maybe not in the resolved-by-the-server-returning-a-304 sense but in at least some sense.

csours• 8 years ago

I'm very surprised that I agree after reading. As I read initially, I was thinking "what about..." but it's really about separation of concerns.

dsl• 8 years ago

It is ironic this is coming out of a company with an internal site dedicated to depreciating "Considered Harmful" because it is the epitome of grandstanding.

Here is some further reading on why we should downvote these types of things into oblivion: https://meyerweb.com/eric/comment/chech.html

gowld• 8 years ago

That's a silly article. The essay says that we should disregard essays if they have a title like the essay's own, so... pradox.

When "considered harmful" is considered flaimbait rhetoric, perhaps the problem is with the readers who refuse to engage with any mildly-worded criticism.

donatj2• 8 years ago

It’s surely in how the reader interprets it, but I always read “considered harmful” as quite mild but to the point. Something like “isn’t great”.

A refreshing opposite of clickbait as the actual proposition is in the title.

devit• 8 years ago

That makes it impossible to properly implement POSIX on top of it and seems like a poor design.

The correct design is to have both a "root" and a "current object" associated with every "file descriptor object" and allow ".." to work up to the "root" (and thoughtfully handle cases where the "current object" is moved outside the "root").

You can't do it with paths because that doesn't track directories being renamed, that would cause the descriptor to suddenly become inaccessible in the middle of an operation.

empath752• 8 years ago

That makes it impossible to properly implement POSIX on top of it

so don't implement posix. I don't know why people get so hung up on new oses being POSIX compliant.

vertex-four3• 8 years ago

Mostly because being POSIX compliant makes it far easier to port a lot of command-line and server-side software quickly. Most new operating system projects don’t have the manpower to rewrite the world - I think the last major one was probably Android.

loeg8• 8 years ago

As I understand it, Fuschia doesn't aim to comply with POSIX.

Your suggestion matches the behavior of "O_BENEATH" in Linux and FreeBSD, or e.g., Capsicum directory descriptors with the CAP_LOOKUP capability.

https://lwn.net/Articles/604015/

https://lwn.net/Articles/482858/

kiriakasis5• 8 years ago

you can define a root filesystem and mount everything you want to access there. the restriction is that your program (or a compatibility layer) should always keep an handle on the root filesystem.

tyingq2• 8 years ago

Rob Pike apparently regrets all the "." file naming.

https://plus.google.com/u/0/+RobPikeTheHuman/posts/R58WgWwN9...

nickysielicki• 8 years ago

This comment made me realize that there are a lot of really good posts on Google Plus by people like Rob Pike, Greg Kroah-Hartman, Linus Torvalds and others. For whatever reason, systems programmers liked Google Plus.

Anyway, I hope someone is archiving them somewhere, because there's a lot of knowledge there that will otherwise be lost in a few months.

z3t4• 8 years ago

I always wondered about the "dot files" convention. That's a really good story! If I knew there where posts like this one I would join in a heartbeat. Where can I find communities like this today !? I always seem to be too late ...

donatj2• 8 years ago

My immediate thought when they announced they were shutting down was "What about Linus's posts?!"

dcbadacd• 8 years ago

Google Plus played less with people's emotions, that's why it sucked as a social media but was quite okay to follow content makers and to manage/participate in groups.

charonn0• 8 years ago

Isn't he talking about something different, though? Specifically the convention that file names starting with "." are hidden?

lottin• 8 years ago

Yep, nowhere in the post does he suggest regretting chosing "." to denote the current working directory.

ori_b• 8 years ago

Reading that post indicates that he regrets the existence of hidden files, not the existence of '.' and '..'

tyingq2• 8 years ago

Yes, that's right. He does have issues with how ".." works in Unix though. There's a pretty detailed explanation from him here: http://doc.cat-v.org/plan_9/4th_edition/papers/lexnames (scroll down to about the third appearance of "..")

cyphar9• 8 years ago

Yes, though Plan9's implementation of ".." Is incredibly different to Unix. It's treated as a lexical token rather than an actual directory entry, and so therefore certain strange cases with symlinks are handled differently (though Plan9 doesn't have symlinks either). From memory Rob Pike had a blog post about this problem and why Plan9 does lexical path cleaning on all paths before resolution.

IgorPartola5• 8 years ago

Your comment is a bit misleading. He is regretting introducing a bug which resulted in creation of hidden files. He isn’t regretting using . and ..

vermilingua• 8 years ago

This may be off topic, and is hard to ask without doomsaying: but can we trust Fuchsia? Google is a machine for turning user's personal data into their dollars, and has been getting more and more crafty at achieving this goal.

I want to believe that this is a good-natured effort at improving the state of modern operating systems; but I feel like I've been burned by my trust in Google too many times.

landryraccoon• 8 years ago

I feel like I've been burned by my trust in Google too many times

I'm genuinely curious about this. In what way do you feel burned?

I think I get what you're saying. I use gmail and Google uses an algorithm on gmail to decide what ads to show me when I do a search. The ads make money for Google and I don't get any of that money. All I get is free search results. I think what you're saying is that because Google is using your information to show you ads and make money that somehow you feel cheated?

But I don't feel particularly burned by this arrangement. If Google gave an option to start charging me money to avoid ads if I'm honest with myself I'm pretty sure I'll choose to continue seeing ads instead. I guess I'm curious about exactly how you feel burned.

eridius4• 8 years ago

Probably the most obvious example is when Google almost destroyed the entire RSS ecosystem with Google Reader.

c3534l• 8 years ago

What about when it turned out Google was tracking users second-by-second location data, even after users had removed consent and turned off locations?

auslander2• 8 years ago

In what way do you feel burned?

By having too much data on me, my friends, my kids, politicians, crunched by AI. It is just too much power, if you think few moves ahead.

StreamBright2• 8 years ago

There is no chance that you do massive surveillance in a microkernel. There might be running an app on the top of the kernel that does that sure, and yes we cannot trust google with mobile OS like Android but I think developing a microkernel is fine.

bun_at_work3• 8 years ago

Just want to point out - Zircon is their microkernel, while Fuchsia is the operating system on top of Zircon. Both are open source though.

brianpgordon• 8 years ago

Well, it's open source. Are there mysterious binary blobs that I'm not aware of? If not, then when this becomes Google's new mobile OS then it's going to be the same as the situation today with AOSP running a bunch of untrustworthy closed-source Google services and apps.

ascii_only• 8 years ago

Fuchsia has different Open Source license. OEM don't have to make their modification opensource. So if you oem you can run any binary blob. Also you don't have to make drivers available.

mjfl• 8 years ago

"considered harmful" considered harmful

The origin of the meme was an editor's labeling of Dijkstra's commentary. Titling your own article this makes it seem like you wrote the article, forgot you wrote it, found it again, and are presenting it to others as an interesting perspective.

vinceguidry• 8 years ago

Coming from Ruby, NodeJS annoys the crap out of me with its lack of decent autoload functionality. Seeing relative paths in modules really annoys me. JS world can't figure out what should be global and what should be local it seems.

ricardobeat• 8 years ago

What do you mean? Global packages are global, local packages are local.

loeg8• 8 years ago

Wrong thread?

hnbroseph• 8 years ago

i really wish the "considered harmful" meme/trope/whatever would take a nap.

DSingularity• 8 years ago

Any good papers to read on fuchsia?

rohan10242• 8 years ago

This is ironic

cd..

Here you go https://fuchsia.googlesource.com/docs/+/HEAD/the-book/

infinity0• 8 years ago

What about shell traversal? [..] For example, if the CWD is “/foo/bar”, and a user calls “cd ..”, then the underlying call may be transformed into “chdir /foo/bar/..”, which can be canonicalized to “/foo”.

So fuchsia also won't have CWD, then? Because if it has CWD, then the process can always chdir / rendering this lack-of-.. exercise pointless.

IshKebab• 8 years ago

I don't see what made you think it won't have a CWD.

rictic• 8 years ago

fuchsia is not posix, so they can (and I suspect have) change the semantics of chdir to be more restrictive.

bun_at_work3• 8 years ago

I think the idea in Fuchsia is that directories can be passed as resources to children processes, which can then move freely around in that directory structure. If the parent passes a child "/foo/bar/", the child sees "bar/" and it's contents, which might be "bar/baz/bingo/". The child can then move to "/bar/baz/bingo/" do work there, and then recurse up the hierarchy. It simply cannot ".." out of "foo/".

Hope that makes sense.

IgorPartola5• 8 years ago

So can a process create a symlink a la

    ln -s ../../.. root

And gain access? Or are symlinks now fucked with too? This seems like a poorly thought out plan, and unnecessary at that.

otabdeveloper1• 8 years ago

This seems like a poorly thought out plan, and unnecessary at that.

Welcome to Google Future (c). Enjoy your stay.

Dot Dot Considered Harmful

Related Stories