On Fri, Apr 5, 2019 at 3:18 AM Jarkko Sakkinen <jarkko.sakkinen@xxxxxxxxxxxxxxx> wrote: > > On Mon, Mar 25, 2019 at 04:55:03PM +0200, Jarkko Sakkinen wrote: > > > > Hmm.. on 2nd thought the LSM policy or even DAC policy would restrict > > > > that the container manager can only access specific files inside > > > > securityfs. With this conclusion I still think it is probably the best > > > > place for seurity policy like things even for SGX. It is meant for that > > > > anyway. > > > > > > > > > > LSM or DAC policy can certainly *restrict* it, but I suspect that most > > > container runtimes don't mount securityfs at all. OTOH, the runtime > > > definitely needs to have a way to pass /dev/sgx/enclave (or whatever > > > it's called) through, so using another device node will definitely > > > work. > > > > OK, I can cope with this argument. I go with the device names above for > > v20. > > In v20 the refactoring would be with corresponding modes: > > /dev/sgx 0755 > /dev/sgx/enclave 0666 > /dev/sgx/provision 0600 > > The problem that I'm facing is that with devnode callback of struct > device_type I can easily give the defaut mode for any of the files but > not for the /dev/sgx directory itself. How do I get the appropriate > mode for it? > Hi Greg- Do you know this one?
