> GNU Rush is a Restricted User Shell, designed for sites providing limited remote access to their resources, such as, for example, savannah.gnu.org. Its main program, rush, is configured as a user login shell for users that are allowed only remote access to the machine. Using a flexible configuration file, GNU Rush gives administrator complete control over the command lines that users execute, and allows to tune the usage of system resources, such as virtual memory, CPU time, etc. on a per-user basis.
> In particular, GNU Rush allows to run remote programs in a chrooted environment, which helps tighten security when offering access over such programs as sftp-server or scp, that access the entire file system by default.
I wouldn't call that revolutionary. As far as I understand, this is a simple alias to something like `podman exec -it somecontainer bash`. We were able to do this for a long time. I mean, it is nice that they provide a simple alias for that. But the marketing talk is a bit much for my taste.
That said, the main benefit is not just that a shell gets a container but that you can easily compose this feature with the container / image ecosystem to deploy specialized shells. Perhaps even you don’t need a VM to service the request but rather a container orchestrator ..
Instead it’s a system replacement shell. Nothing to do with your running containers. Instead it seems to let you sandbox users on your VM/baremetal to a container.
Several times I tried to use podman on mac to replace docker tooling, the idea of daemonless-rootless is enticing. However, there's always things that doesn't work or work differently on podman that make it not easy to work in team that predominantly using docker.
Usually it's about networking setup or compose compatibility.
Maybe someone encountered similar situation can share your experience.
I had the same experience for a while, and was a little bitter about repeatedly taking them at their word that you could transparently `alias docker=podman`, even when Podman 4.0 didn't even support volume mounts from the host without jumping through hoops.
I suggested that the team document or at least label compatibility issues so users are informed about them, but they rejected the idea[0], recommending instead that users keep abreast of changes to a 35 page troubleshooting file.
That said, I've been living on it full time for a few months, and it's working well. I'm using the Docker CLI with Podman providing the backend implementation. Biggest caveats: Mounting volumes from the host is still a little limited. It doesn't play nice with giving docker.sock back to Docker Engine (wontfix[1]). The --platform flag was broken but should be fixed in 4.6.
I was also a victim of “just alias docker to podman” advertising. I couldn't run even a single container with podman on my Mac. I'm happy to have given up early with their BS.
`BS` is a bit unfair.
It is true that podman-desktop is a bit rough around the edges still, but it is in no worse shape than docker-desktop used to be when it was a year and a half old project.
With the release of podman 4.6.0 a lot of the issues have been sorted out, podman-desktop is still shipping engine 4.5.1 at the moment, but a new release should be coming out soon.
I'd suggest you give it another shot.
it’s bs because they have elected to not maintain cli compatibility on many areas. not because they “haven’t gotten there yet” but because they don’t agree with docker. they converted into technological amish that think the one true cli is not the current one.
> podman on mac to replace docker tooling, the idea of daemonless-rootless is enticing
I'm confused by this one. You're already running a VM in order to use containers on a Mac. What does the daemonless approach inside a container give you? That feature works great on Linux servers for me, but I'm not sure what's the point outside of that.
Kinda, a bit, it's hard. So podman will need virtualisation and networking permissions to do its job. Also the directory mapping seems to work without extra confirmation. At that point, who needs root? You control the main user`s files, networking, and can effectively hide any process from easy inspection by using virtualisation.
The old problem with Podman was always was that it was never exponentially better. And I don't believe, at this point, that Podman will ever replace the Docker ecosystem. And now the problem is that I view RedHat/IBM as hostile to open source, so there's no way I'm going to use or recommend it - just the same way I stopped considering using Windows platforms post Windows 2008 timeframe.
not sure I understand the hostility to Red Hat, or how they might be hostile to OSS .. didn't they create podman on OSS, continue to develop and support it and give it away?
podman is supposed to be more secure than docker. How do they reach improved security? By limiting access to the system that could be dangerous if misused. Obviously with additional limitations comes incompatibility. If your image tries to do something that is no longer allowed the same way, it won't work the same way as before. Compatibility exists only for images that don't do anything potentially dangerous. Ironically enough for those you would not need podman. But it's of course still a good idea to use it. Few people know in every detail what their images are trying to do.
I’m not averse to things that introduce complications for security, but it’s very poorly advertised. The overall impression a new user gets is that podman should just work as a Docker replacement, and this is frequently untrue. My own experience is that I started using podman when docker on Fedora wouldn’t work with cgroups v2. Iirc, I could (and should) have made configuration changes to make Docker work, but I wasted a lot of time tracking down issues because I thought podman would have better compatibility than it had.
Upthread there’s a good suggestion that the authors should create an explicit compatibility document.
True. But the community around docker makes it better for local use. If you really need something more, a minimal kubernetes distro is a much better option for little additional work (if any).
I see some misunderstanding of the goal of Podmansh. The basic idea is certain users have secure systems where they want to allow limited access to the host system.
For example you might have some secret data on a system, where a user can only see certain data depending on who they are, you also want to prevent said user from seeing other users or processes are running on the system. Podmansh makes setting up these types of shared systems easier.
People are correct in thinking podmansh is just a single command that `podman exec -ti podmansh` container, and they would be correct. But the interesting thing is through the user of quadlet and systemd, administrators can easily configure the podmansh container for all users or for specific users. The ease of customization and systemd managing the life cycle of the container based on users sessions is a really nice feature.
Many users will never use this, but certain users like Governement, Banking or other entities who are very concerned about security, this is a really nice feature.
When I read the title, I expected that I'd finally be able to use Podman containers for my development environments & shells (i.e. inside my existing user account), for reproducibility purposes and to protect against the most trivial of supply chain attacks etc. Unfortunately, this is not entirely trivial (think IDE integration; also, one likely wants to use both personal shell commands and project-specific commands on the same command line). So I was hoping the Podman devs had found a good solution here.
Not really sure what one would use a login shell for, though. I mean, if I, as the user, am merely logging into a containerized shell, why don't I execute the container locally? Why use SSH? Sure, the volumes mounted into the login shell container might contain data I need, but one could also simply mount them as network storage locally.
Have you looked at toolbox? it might already be doing what you want — it's a thin wrapper around podman that integrates containers with the rest of the system — you don't really even feel that you're running a container.
Thin client is one answer to your question. Running a shell to a server results in significantly longer endurance for a client on battery than otherwise. Not swamping your system's I/O bus is another. OS incompat. Regulatory shenanigans.
Then there's also the training angle. I've found nothing quite as tangibly gets the visceral sense of computing across like walking a junior through a "where are your bits now?" now exercise with a handful of physical boxen.
Last I looked, distrobox made $HOME fully accessible to all its containers. That's the very opposite of parent comment's "protect against the most trivial of supply chain attacks".
Podman is in universe, so it's not really supported by Ubuntu. It's always worth checking what you use that's in universe, as if you're mostly using universe, I'd start looking at a different distro.
Yes in the research computing world (HPC and similar systems, and some other sorts of shared resource) at least. On Linux-based machines you can limit resources otherwise, via PAM, or startup of interactive sessions in a distributed resource manager ("batch system").
I've been using UNIX-like machines (mostly Linux) since the mid-2000s and single-user machines have always been the exception rather than the norm everywhere I've been.
Even at home, I've set up multiple accounts for myself (main one, one for closed-source programs, one for gaming I can share with other people…) and for my family (to each their preferences, wallpaper and so on). Having two or three user sessions running at the same time is not uncommon. I'm probably the exception here, but I don't think Podman targets the regular home user anyway.
It's not obvious to me how Podmansh would revolutionize that, but I guess it's nice, I'll try it for sure.
I feel that at times projects should start focusing on improvements on stability and ability to maintain code, instead of adding complexity to complexity over an already complex set of resources, the devops industry is out of ideas and keeps creating issues and then trying to sell products in order to manage that complexity, In my projects I manage CI/CD with very small overhead, why I am writing this complaining message of hate of devops industry is because when you go to work for companies of people who just adopt anything thrown at them then everything seem so senseless
If you are out of ideas to improve products, pause, think and improve code and other stuff, it’s not written in store that there should be new functionalities every day
Which has been something people have been doing for years now. It isn't any notable added complexity that isn't usable in other contexts (they added a timeout feature for handling errors better), and it isn't new functionality.
Can any grey beard types explain to me why someone would throw users into containers instead of their own user accounts with permissions? Why is the desired level of isolation not possible or too difficult without them?
The regular shell is a huge attack surface, including user-to-user attacks and overly permissive network access.
Frankly, ssh-to-container is a "slaps forehead" obvious solution and I'm surprised none of us thought of it before - I'd love to see it as a standard option in the OS, e.g. chsh allows you to specify a container and optional port and volume mappings.
In the old days, we'd (try to) use chroot, but that has all sorts of big problems with needing access to various directories, and those batches begat patches...
We replicated the behavior (somewhat) of the article, using podman, as a way to allow devs to SSH into a container that was identical to the CI/CD environment.
It also mapped in their NFS home drive, so they could quickly SSH into the container to try a build, to see if it was their dev machine, or a real issue.
It did allow them to choose their container though.
I'm not sure if the attack surface is effectively reduced with the use of cointainers. Of course, the user is now in his own namespace, but in order to achieve this, an additional file system, another network interface and a container runtime have been added, thus effectively doubling the complexity.
Containers are great if you want to present a service to the outside world or if you want to set up a clean workspace locally. But I wouldn't be comfortable with the thought of letting someone I don't trust into the server behind the firewall.
Depending on the configuration, you can reach other local containers via localhost:${port}. An with overlayfs there was afaik a case where you could actually access restricted areas of the underlying filesystem.
These arguments are painting a bike shed: the attack surface is not zero but it's still dramatically reduced and controlled. Nobody said anything about "letting someone I don't trust into the server behind the firewall" which of course is (cough) "not best practice."
Also, containers mean that one user can make changes (install/upgrade software, etc) and not adversely affect another user (incl their security stance).
Since most package managers only support installing software system-wide, users need to compile whatever additional software they need in their home directory and hope that the prerequisite toolchains are already installed by their system administrator. Isolating users in containers allows them to customize their environment via `sudo [apt/yum] install` just like they would on their own computer without affecting other users. Containers can give each user apparent sudo powers while confining all of their operations to their own sandbox. They are a lighter-weight alternative to allocating a full VM to each user.
Not sure. When the shared hosting pattern was popular, it needed to support the users running background daemons that ran all the time, plus things like "cron" and "at", etc. It's not very clear, but the article reads like none of that would work.
Podman installs a systemd generator that automatically transforms the name.container files shown in the article into ordinary systemd user service units[1][2][3], so
loginctl enable-linger USER
(run once, as root) should cause USER's podmansh container to start as soon as the system enters multi-user mode, independent of USER's login sessions, allowing persistent daemons, including those necessary for job scheduling, namely…
Ordinarily, users can create systemd timer units[4] to schedule at- and cron-style jobs; I assume you need to run a systemd instance inside each user's podmansh container to allow users to create systemd units in the present containerized context (running systemd inside a container is explicitly supported by podman[5]).
If your users don't like systemd, you can also run traditional atd/crond daemons in user containers.
There are PAM croup and namespace modules to limit resource use and isolation on Linux-based systems. Obviously they're using the same bases as containers.
> GNU Rush is a Restricted User Shell, designed for sites providing limited remote access to their resources, such as, for example, savannah.gnu.org. Its main program, rush, is configured as a user login shell for users that are allowed only remote access to the machine. Using a flexible configuration file, GNU Rush gives administrator complete control over the command lines that users execute, and allows to tune the usage of system resources, such as virtual memory, CPU time, etc. on a per-user basis.
> In particular, GNU Rush allows to run remote programs in a chrooted environment, which helps tighten security when offering access over such programs as sftp-server or scp, that access the entire file system by default.
https://www.gnu.org.ua/software/rush