i've been away for a few days and hence the late update.... On Thu, Sep 2, 2010 at 11:51 AM, Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx> wrote: > Hi Pavan... > > On Thu, Sep 2, 2010 at 22:09, Pavan Savoy <pavan_savoy@xxxxxxxx> wrote: >> Hi, >> >> I use kill_pid in one of our drivers to signal a user-space daemon to >> perform a particular action (open-UART for instance), I recently ran >> into problems with permissions as to when a user with stranger UID >> started open up a device, which internally calls the kill_pid in that >> context, could not send the signal and returned with "permission >> denied". > > Hmm.... what if you create a char device, make the daemon select() to > this file...and through this char file, you send the neccessary > command? what do you think? All I want to do is notify some change in the kernel for user-space to take action, the notification had to be simplistic, char-device + fasync + SIGIO or netlink sockets or even mmap.. seems all bit too complex for the simple requirement I have... kill_pid serves the purpose just right... > or you stay with signal...but directly manipulate the sigset (signal > set, the structure that represents the queue of the signal on a > certain task_struct IIRC). Forgot which functions that do that..so try > to explore it. If I had to do this, I wonder why kill_pid function is exported in the 1st place... right? yes.. it does sound complicated.. but will certainly have a look at it.. the problem is I don't have "current"... >> I started using kill_pid_info_as_uid and sent signals as UID 0 to >> solve the problem, it did solve the problem, but is this the right >> approach? > > In the sense of simplicity, I say "yes, you can do that way". But when > you think about security, I don't think it's wise. Just think..what > happen if it's a malicious program that send unexpected pattern thus > triggering "crazy" command on the target daemon? or at least, that > means anybody could send any command to the daemon. Do you really > really believe you can trust *any* user in the system? > hnm, well the daemon which I intend to run is pretty simplistic too.. as in it only responds to 1 kind of signal, does nothing critical to system (just opens a UART...) and someone else probably cannot write in any random PID to the sysfs entry since it root only accessible and my daemon runs as root... >> Also why is not suggested to use kill_pid and family to communicate >> with user-space? (namespace issues??- what do they mean?) > > Namespace? ok..in short words, it's like "realm". We have PID > namespaces, meaning array of PIDs in certain realms. You use virtual > machine sometimes, right? virtual machines create "pid" too, it's just > it's not a real PID like the one that represents a task in real host. > > Filesystem namespace.....perhaps confusing too....you ever use chroot? > that's a good example...you leave one root based filesystem (ones that > mounted in /etc/fstab and all of your manual mount command)...and > switch into chrooted filesystem. > > Spell it slowly..."name"...."space"... space of names.... > dimension...realm...you call it ;) still wondering.. see the name-space in which my daemon runs has a PID and the same PID is written to the sysfs entry... Is there a chance of the same PID to exist in another name-space? (say init running on virtual machine ?) and when I want to notify it from my driver, I send say SIGUSR2.. does the signal go onto both process and thereby terminating the init on virtual machine? (hypothetical situation...) ? Is that what the problem is or could be? I still do find_get_pid to figure out the PID which takes in the name-space via the current->nsproxy->pid_ns - so isn't this a sure shot way of getting to know which name-space my PID belongs to while sending signal ? again the question .. if this is all a security issue, why bother EXPORTing the symbol in 1st place ? (bit of background...) requirement is pretty simple: I need to open-up UART from the kernel-space and send some data, the way TTY(over UART) is today is very unlike SPI/I2C or any other peripheral interface, and allows data communication over UART via user-space only ... (no I don't want to be bothered about the adapter driver.. as in what driver drives the UART on what sort of platform...) What I did was to use kill_pid to send SIGUSR2 from my kernel space driver code to user-space daemon to open UART and install a line-discipline ... and then on my ldisc driver could write data on UART as and when it wanted... > -- > regards, > > Mulyadi Santosa > Freelance Linux trainer and consultant > > blog: the-hydra.blogspot.com > training: mulyaditraining.blogspot.com > -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
