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. I think this part may be critical for understanding your point of view. Thanks. > > From my perspective, netlink is a lot like ioctl, only without the > meaningful fd that you're calling it on. So why is it better than > syscalls? I'll grant that it comes with nice (?) buffering machinery. The nice buffering machinery is one of the reasons. Another reason is that netlink is a ready interface for this sort of task, so we can avoid code duplacation. > > > * Netlink is designed for such type of workloads. It allows to expand > > the interface and save backward compatibility. It allows to generates > > packets with a different set of parameters. > > * If we use a file descriptor, we can create it and decrease > > capabilities of the current process. It's a good feature which will be > > unavailable if we decide to create a system call. > > If this is actually a real goal and it matters, then I'd suggest doing > it right. Make a way to create an fd that represents a pidns and, > specifically, the right to query non-secret properties of the > processes in the pidns. I will think. Thank you for comments. > > --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
