Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

And not only for running processes, but also for files on the disk. If you mount an image on the host and make a file owned by "root", then mount that image in a container, the container's "root" now owns it too.

Edit: Note that userids are the same, but usernames are not managed by the kernel (handled by /etc/passwd or LDAP or something), so userid 1001 inside the container is userid 1001 outside, but they might have different names if you "ls -l" from different places.



See also (1)mount's nosuid/nodev options, because plugging in a USB stick with a setuid-root shell on it apparently used to work.


Or, years before, NFS: the NFS permissions model trusts the client and server implicitly. In many environments, that meant that getting root[1] on any system quickly cascaded across all of them if you could write to, say, someone's shell profile, SSH keys, or a shared binary in a common location — which was not uncommon at all when people were trying to conserve storage costs by only installing things in one place. No suid, nodev, and the various options for preventing uid=0 access were all attempts to bandaid around the lack of a better authentication option until people started switching to Kerberos.

1. Or, if they didn't require trusted ports, any account at all using https://github.com/NetDirect/nfsshell




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: