So I am currently learning how LXCs work and one of the things i dont really understand is how it isnt a security issue that multiple LXCs are mapped to the same host users.

From my understanding a user inside an unpriviledged container gets mapped to its container user id +100000 on the host, so user 1000 inside the lxc is going to be user 101000 on the host.
Doesnt that also mean if i got multiple LXCs that all have the inside user of 1000 they all get mapped to the same user (101000) on the host?

Doesnt that mean if there is a container break out on one of the containers all other containers that have a user with the same id could be accessed too? (and all the resources they have access to?

THanks & sorry if this is a dumb question, but couldnt find much on that exact situation :)

I am currently redoing the network on a location i use for offsite backups, WAN is 10G/10G.

The plan was originally to to built an opnsense box with a 9th or 10th gen i5 or i7 (probably i5 9500) but a couple days ago i got a great deal on a supermicro board (with also more pcie slots for extra NICs than the consumer boards) with an E3 1220V6, so now i am thinking about using that instead.
As NIC i already got an Intel 710-DA2.

Do you think this cpu would be enough for 10G Firewall / Routing and close to 10G over Wireguard (at larger Package sizes)?

Any guess how slow it would get if i turn on DPI / IDS?

Would it make sense to upgrade to an E3 1270 v6 or 1280 v6?

Currently trying to run a SMB Server managed with Cockpit on an unprivileged LXC Container (Proxmox) and looking to double check regarding security.

The original idea was to keep everything besides the actual data of the network share on the rootfs and then create a Mountpoint for the actual files of the smbshare.

The issue is that (without additional user mappings / configuration on the proxmox host) only the container root user can access the mountpoint. If any of the SMB Clients try to access the share they get a permission denied from the filesystem (even when permission are set to 777, i am also not using ACL for now)

If i set the option "force user = root" in the smb config all the read write operations of the smb users are now performed as root user and everything works.

All the authentication / read write permissions is done via the smb config (valid groups, read only = yes, write list etc) the smb server / lxc only hosts one shared folder with the path set to the mountpoint, the lxc container runs unpriviledged without any arguments like nesting and strong authentication and only hosts this one network share.

Considering those things, how bad would the force user = root settings be in therms of security?

Lets say i got 5 network storage servers / lxc all running smb as well as sftp (or sth else that uses normal linux auth), they all host different network shares / data, now i am trying to sync all the user accounts, both linux and samba (samba uses different hashing), that i dont need to manually create / change password of each client account on each lxc individually.

I have spend the last week trying to get ldap (via 389 directory) to work and i am just done... after several other things i am now stuck trying to figure out how to allow smb to authenticate against the ldap server since it uses a different hashing than standard linux auth and i found so many conflicting infos online.
Also the management (creating users / assigning them to groups via the cockpit plugin is just a pain...

I am wondering if it wouldnt be just the easier option to hard sync / mount all the /etc/shadow /etc/group /var/lib/samba/passdb.tdb files between all the worker nodes... Since all the configuration would be done on the controller, it should even be possible to mount those files in read only mode on all of the workers.
How bad is this idea?
How likely is this going to work / break?

Any advice appreciated :)

The full setup plan is:
- One Controller VM that runs debian and cockpit including the 45drives navigator and identities plugins for management (up until now also a 389 directory server)
- The Controller has all the network shares of the workers mounted and viewable via the browser cockpit 45drives navigator plugin, allowing for easy data viewing and transfer between multiple networkshares / workers
- The goal is to do all the management centralized via the cockpit interface running on the controller
- Multiple Worker Nodes / LXCs - that all run debian with smb installed, besides the actual data stored in the host mountpoint /data they are all identical - each worker only hosts a single network share
- All of the above running on proxmox backed by ceph or zfs (depending if HA is needed for the particular Network Share
- Since each smb share is inside its own container transferring the entire share to another node / physical server is easily done via the proxmox migrate function

• Plan for the permission setup was to create two groups for each worker node (hostnameofworker-rw and hostnameofworker-r) and grant those groups permissions inside the smb config and set the permissions on the filesystem of the /data via ACL accordingly
  
• The smb config is setup in a way to grant acl permissions recursively to both of those groups on the entire share
  
• Then just assign all the Client users to all those groups to grant them permissions
  
• This assignment would be done ether manually via the controller node or automatically via some of the deployment scripts (when i am adding a new share / worker node for example)