On Dec 13, 2015 11:52 PM, "Andrew Vagin" <avagin@xxxxxxxxxxxxx> wrote: > > On Thu, Dec 03, 2015 at 03:20:30PM -0800, Andy Lutomirski wrote: > > On Tue, Nov 24, 2015 at 7:18 AM, Andrew Vagin <avagin@xxxxxxxxxxxxx> wrote: > > > Hello Everybody, > > > > > > Sorry for the long delay. I wanted to resurrect this thread. > > > > > > Andy suggested to create a new syscall instead of using netlink > > > interface. > > >> Would it make more sense to have a new syscall instead? You could > > >> even still use nlattr formatting for the syscall results. > > > > > > I tried to implement it to understand how it looks like. Here is my > > > version: > > > https://github.com/avagin/linux-task-diag/blob/task_diag_syscall/kernel/task_diag.c#L665 > > > I could not invent a better interfaces for it than using netlink > > > messages as arguments. I know it looks weird. > > > > > > I could not say that I understood why a new system call is better > > > than using a netlink socket, so I tried to solve the problem which > > > were mentioned for the netlink interface. > > > > > > The magor question was how to support pid and user namespaces in task_diag. > > > I think I found a good and logical solution. > > > > > > As for pidns, we can use scm credentials, which is connected to each > > > socket message. They contain requestor’s pid and we can get a pid > > > namespace from it. In this case, we get a good feature to specify a pid > > > namespace without entering into it. For that, an user need to specify > > > any process from this pidns in an scm message. > > > > That seems a little messy. A process can't currently move into > > another pidns, but how do you make sure you have any pid at all that > > belongs to the reference pidns? You can, of course, always use your > > own pid, but that still seems odd to me. > > There is your pid by default, you need to do nothing for that. > If we look at containers or sandboxes, we ussualy know PID of > the init process. > > > > > > > > > > As for credentials, we can get them from file->f_cred. In this case we > > > are able to create a socket and decrease permissions of the current > > > process, but the socket will work as before. It’s the common behaviour for > > > file descriptors. > > > > Slightly off-topic, but this netlink is really rather bad as an > > example of how fds can be used as capabilities (in the real capability > > sense, not the Linux capabilities sense). You call socket and get a > > socket. That socket captures f_cred. Then you drop privs, and you > > assume that the socket you're holding on to retains the right to do > > certain things. > > > > This breaks pretty badly when, through things such as this patch set, > > existing code that creates netlink sockets suddenly starts capturing > > brand-new rights that didn't exist as part of a netlink socket before. > > Sorry, I don't understand this part. Could you eloborate? Maybe give an > example. > > I always think that it's a feature, that we can create a descriptor and > drop capabilities of the process or send this descriptor to an > unprivilieged process. Suppose there's an existing program that likes this feature. It creates a netlink socket, optionally calls connect(2), and then drop privileges. It expects to retain some subset of its privileges. The problem is that by increasing the power of a netlink socket created with higher-than-current privilege, you've just increased the privilege retained by the old app. In this particular case, it's especially odd because it retains privilege over the old pidns, whereas the old program (in theory -- probably no one does this) could have created a netlink socket, unshared pidns, and forked, and it would have expected to retain no privilege over the old pidns. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
