Hacker News Reader

Comment by zamalek | Hacker News Reader

The biggest advantage of Bard is the speed, it's practically instant.

I asked: How would I go about creating a sandbox directory for a subordinate user (namespaced user with subuid - e.g. uid 100000), that can be deleted as the superior user (e.g. uid 1000)? I want this to be done without root permissions.

Both said that it's impossible, which is the the generally accepted answer.

I then added: I don't care about data loss.

Bard correctly suggested mounting a filesystem (but didn't figure out that tmpfs would be the one to use). ChatGPT suggested using the sticky bit, which would make the situation worse.

Handing this one to Bard, especially given that it generated more detailed answers much faster.

View on HN

> How would I go about creating a sandbox directory for a subordinate user (namespaced user with subuid - e.g. uid 100000), that can be deleted as the superior user (e.g. uid 1000)? I want this to be done without root permissions.

Off topic, but it feels so weird that this is not possible. I've run into this with rootless Docker recently.

It is possible, but I suspect my solution may be novel (I got nothing so I continued banging my head against the wall until I figured it out): https://github.com/nickelpack/nck/blob/main/crates/nck-sandb.... The trick is to put everything in a tmpfs, then lazy umount when done. Overlayfs might also be able to pull it off with uid= (I'm not sure if it actually supports it).

Container runtimes, apparently, usually have a setuid helper that deals with this stuff. You could also have PID 1 in the namespace clean things up.

That being said, you'll likely run into more problems with root and apparmor etc. Setuid is probably unavoidable for secure sandboxes.

You can make the "superior" user a member of the default group for the user, and set the umask of the sandboxed user to allow group write by default.

Though that doesn't help malicious/"odd" use cases that can just reset the umask, or otherwise remove the group permissions from the subuser's files.

Or just use posix ACLs? Though you may then need to disallow the subuser from just removing them, maybe through seccomp?

If you ever try it on Gemini let me know I am curious.

As of today, Bard is now powered by the Gemini Pro model mentioned in the article. Bard Advanced is set for release early next year and will be powered by Gemini Ultra.

> The biggest advantage of Bard is the speed, it's practically instant.

They probably have less than 1% of OpenAI's users. That helps.

> (namespaced user with subuid - e.g. uid 100000), that can be deleted as the superior user (e.g. uid 1000)

I'm afraid I don't know what this means. That when you delete uid 1000, uid 100000 also gets deleted? Or, only user 1000 has permission to delete user 100000 ?

Bard currently is GPT-3.5 class model. Of course it's faster than GPT-4. (YMMV on specific examples of course)

Reply on news.ycombinator.com