Yesterday npmccallum on #gentoo-dev made me note that eject can unmount partitions just by root for a permission problem (well not exactly a permission problem, I knew of that and I thought it’s right basically), and that it should use pmount, a suid mount wrapper, to do the actual unmount…
Ok now I’d really like to have unieject working on most systems as possible, so I don’t want to constrain it in any way. I think it’s really really important that it’s designed, wrote and used in the more flexible way as possible. So I’m thinking of getting this stuff working, maybe via a configuration file to use as “run this command to unmount”.
Surely, that’s possible but… I’m still thinking about this: I don’t like system() calls because you rely on someone else to do the job, in this case I should do a system() call to execute a suid executable. I’m not sure if this is the right way to go at all.
At this point one can just suid unieject, and it will work out of the box, being it suidded it can unmount the partitions without permission problems also by root.. and actually it just needs a “capability bit” to be able to do that, as the umount() call in glibc just requires CAP_SYS_ADMIN capability.
Every comment is welcome.. should I just make unieject use a system call to call a suid executable, or just create a wrapper with the capability?
Oh and BTW I started preparing for gettext the project, so starting from version 3, translations will be possible.
As a pmount/pumount user, i’m all for some exec() calls of external commands, like in eject (with addition of the user-defined one you’ve suggested, which is a very good idea): – pumount is not just a suid umount; it also delete the mount point if it was created by pmount, and that’s probably not a feature you want to rewrite in unieject. – the less suid binaries i have, the better. Since i have pumount suid already, it sounds like uneeded duplication of the risks to suid unieject just for the same task.