Re: [DNG] automount, mount, and USB sticks
Hi, Laurent Bercot wrote on 29/07/2015 at 17:34 CEST: On 29/07/2015 17:07, tilt! wrote: I am certain there is a way of solving this automounting problem (if I may call it that) cleanly, without the use of either of them. :-) There is a way to solve (almost) every suid issue cleanly, but it requires running a small additional daemon for every command you might want to run with special privileges, so this is not a generic solution - but it can work for automounting. http://skarnet.org/software/s6/s6-sudo.html The daemon-based solution has its upsides: (1) One problem / One program = do one thing right. (2) Indirection via an entangled policy management service or a possibly omnipotent commandline is avoided. (3) System behavior of automounting was easily enabled and disabled per service automount start/stop. My estimate is that such daemon was not resource hungry: We are talking automounting on manual hotplug, with a latency in the seconds, so a 1s polling interval was more than sufficient. We are talking device changes maybe every few minutes (on busy days), so it does not have to buffer many requests either. We are talking single-user, so even with management of an idle-umount policy there is not much state to take care of. That is, of course, unless someone finds it should also do automounting of network file systems, possibly on a mobile, roaming device, from flimsy cloud services; then things could get ugly fast ... but that is not what we're talking about, right? Kind regards, T. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automount, mount, and USB sticks
On Wed, 29 Jul 2015 17:07:32 +0200 tilt! t...@linuxfoo.de wrote: I am certain there is a way of solving this automounting problem (if I may call it that) cleanly, without the use of either of them. :-) Yes, a daemon running as root could do it. And if the daemon does nothing but observe inotify and dmesg, perhaps check a fifo for devices to be mounted/unmounted (with complete cleansing of that fifo's information) and perform a mount command, I imagine we could get a handle on security. SteveT Steve Litt July 2015 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] nlmon
Isaac Dunham ibid...@gmail.com writes:
On Wed, Jul 29, 2015 at 01:21:04PM +0100, Rainer Weikusat wrote:
Isaac Dunham ibid...@gmail.com writes:
Or you can do it with mount, sudo, sh, and nlmon
(http://git.r-36.net/nlmon).
Using poll to wait for a message followed by recvmsg for reading it
offers (in absence of a timeout) no advantages over just doing a
blocking recv. Since this code neither uses control messages nor looks
at the returned flags, it can use recvfrom instead of the (more
complicated) recvmsg. Considering that it checks for message buffer
overflow via len = sizeof(buf), the MSG_TRUNC flag should probably be
used to make the kernel return the real size in case a datagram was
truncated. Lastly, the message doesn't have to be copied to a 2nd buffer
just to turn the 0-terminated name=value pairs into \n-terminated ones.
NB: I admit that I mainly did this because it looked like a nice, simple
programming task.
A few comments:
- I'm not the maintainer, and I don't see why this got sent here.
- There's no reason to factor out print_event_if, and the code it replaced
is clearer and more concise.
There's a very good reason to do that, namely, it's a separate task
working with its own set of variables, even in the orignal code. And
something which boasts of its light-weightness should keep rescanning
the same data over and over again just because that's what the standard
C library str*-functions will do when used naively or in situations
they're not well-suited for, eg
for (i = 0, olen = 0; i len; i += slen + 1) {
slen = strlen(buf+i);
if (!slen || !strchr(buf+i, '='))
continue;
At this point, what would really be needed is a function which returns
a pointer to the next '=' or '\000' but C doesn't provide one.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automount, mount, and USB sticks
On 29/07/2015 17:07, tilt! wrote: I am certain there is a way of solving this automounting problem (if I may call it that) cleanly, without the use of either of them. :-) There is a way to solve (almost) every suid issue cleanly, but it requires running a small additional daemon for every command you might want to run with special privileges, so this is not a generic solution - but it can work for automounting. http://skarnet.org/software/s6/s6-sudo.html -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automount, mount, and USB sticks
Arnt Gulbrandsen a...@gulbrandsen.priv.no writes: Steve Litt writes: I repeat my question: Do you have first hand knowledge indicating that polkit is any safer? No, I do not. But unlike sudo, I am not aware of any weaknesses in its core design either. You wrote that sudo would keep the PATH environment variable of a user when executing commands, hence, if these other commands in turn execute programs found by searching in PATH, this would enable a user to run an arbitrary programs which is correct. But this is a potentially exploitable weakness in some other program, not in sudo itself, and if 'allow users to run arbitrary programs as root' is not what's intended, they obviously mustn't be allowed to run programs as root which - in turn - enable execution of arbitrary, other programs: That's no different from any other kind of possible exploitable weakness in code running with elevated privileges on behalf of some otherwise unprivileged user. And how to handle PATH is not a core design property, it's a configurable option and 'keep it' just the default policy. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automount, mount, and USB sticks
On Wed, 29 Jul 2015 11:04:22 -0400 (EDT) Rob Owens row...@ptd.net wrote: Spacefm has the ability to use several different methods to mount removable media. If you install either pmount or udevil, it can use them. By default, I believe it automatically chooses which method it wants to use, based on what you have installed. [snip] On Jessie, I have noticed that some applications don't properly detect the mounted removable media if it's mounted this way. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774871 I shall do a base install of Devuan and add Xorg/window manager and have a play with this on Friday and see what I can find in the way of bugs. Thanks -- kpb k...@sohcahtoa.org.uk ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automount, mount, and USB sticks
Steve Litt writes: I repeat my question: Do you have first hand knowledge indicating that polkit is any safer? No, I do not. But unlike sudo, I am not aware of any weaknesses in its core design either. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automount, mount, and USB sticks
On 29/07/2015 16:02, kpb wrote: That is a really interesting way of looing at things, thanks for the mental prompt. It's an elementary design principle: separate the engine from the interface. I very much hope people who design GUIs keep it in mind. How would you deal with providing notifications to a GUI layer if present? Have a general notification mechanism present, such as a bus (and no, I'm not advocating D-Bus). Then have your GUI clients register on the bus and subscribe to the events they're interested in, just like any other client would. But that's for the general case. In many other, specific cases, there will be a communication stream from the command-line utility to its caller; if the GUI is the caller, it can simply keep the command-line utility alive and use the stream of information it's getting from it. -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automount, mount, and USB sticks
On Wed, 29 Jul 2015 18:41:36 +0200 Laurent Bercot ska-de...@skarnet.org wrote: I know the advantages of the daemon approach, I use it myself and advocate it any chance I get. Unfortunately, I have found that many users are reluctant to add yet another daemon to their systems, no matter how few resources it takes, no matter how big a security hole it plugs. And certainly there's a certain humor to the preceding paragraph, as anyone who has performed: systemctl list-dependencies default.target I don't remember the exact syntax of the command, but the list of daemons rivals War and Peace in length. How a person using a system like this could object to another daemon is beyond me. SteveT Steve Litt July 2015 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OT: some ancient programming language history
On Mon, Jul 27, 2015 at 5:16 PM, Lars Noodén lars.noo...@gmail.com wrote: IIRC the Icon programming language had an exchange operator to swap the contents of two variables. a :=: b C: a = a ^ b; b = a ^ b; a = a ^ b; Much more fun. Them :=: look like weird emoticons. -- On the internet, nobody knows you're a dog. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automount, mount, and USB sticks
Le 29/07/2015 16:35, a...@gulbrandsen.priv.no a écrit : Every last problem of sudo is taken seriously? Did you know that if someone has limited access, e.g. the right to install standard packages, then it is easy to leverage that to get complete access. Various packages run programs in $PATH as root, Firefox comes to mind, so just prepare $PATH and sudo apt-get install firefox. Sudo leaves the user's $PATH and the rest is just a matter of finding the right exploit. Was open for years, may still be open. Arnt I don't understand the preventions against sudo. It is just up to the administrator to take care, like for everything. Wether execution of the command is allowed by sudo, by a setuid bit or by policykit does not change the result. Sudo is simply the most versatile method to allow/disallow actions, IMHO far easier to configure than policykit. Don't forget that allowed commands may (should) be specified with their absolute path, therefore bypassing PATH. It is better than having a specialized daemon for this and that, because it keeps everything configured in one well known file. In the case of mounting usb sticks, this applies to a personal computer, where the owner is also the administrator. For conveniency, a limited list of actions may be allowed without password, like mounting a usb key. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automount, mount, and USB sticks
On July 29, 2015 7:17:23 PM GMT+02:00, Steve Litt sl...@troubleshooters.com wrote: On Wed, 29 Jul 2015 17:07:32 +0200 tilt! t...@linuxfoo.de wrote: I am certain there is a way of solving this automounting problem (if I may call it that) cleanly, without the use of either of them. :-) Yes, a daemon running as root could do it. And if the daemon does nothing but observe inotify and dmesg, perhaps check a fifo for devices to be mounted/unmounted (with complete cleansing of that fifo's information) and perform a mount command, I imagine we could get a handle on security. *very* interesting thread sorry for stating the obvious I guess that's why you are all here IMHO the bigger barrier to this is not having a string parsing code (or basic grammar) that is security oriented, I mean hardened to run as root and handle corner cases I mean: what would you suggest using for the check a FIFO bit you mention? pcre? perhaps very clean simple code? most code out there has too many features and is too ambitions to fulfill such a simple task said that: yes, I do watch my process list and think that smaller is better. I think I speak for most people here when I say we dislike the quantity of undocumented daemons running on on gnu/Linux desktop nowadays and I hope we can trim that down with Devuan how I do it now? hardcode every single binary that sudo is aloud to execute, full path and locations that are only root writable. that's a sudoers feature... ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] nlmon
On Wed, Jul 29, 2015 at 05:17:30PM +0100, Rainer Weikusat wrote:
Isaac Dunham ibid...@gmail.com writes:
On Wed, Jul 29, 2015 at 01:21:04PM +0100, Rainer Weikusat wrote:
Isaac Dunham ibid...@gmail.com writes:
Or you can do it with mount, sudo, sh, and nlmon
(http://git.r-36.net/nlmon).
Using poll to wait for a message followed by recvmsg for reading it
offers (in absence of a timeout) no advantages over just doing a
blocking recv. Since this code neither uses control messages nor looks
at the returned flags, it can use recvfrom instead of the (more
complicated) recvmsg. Considering that it checks for message buffer
overflow via len = sizeof(buf), the MSG_TRUNC flag should probably be
used to make the kernel return the real size in case a datagram was
truncated. Lastly, the message doesn't have to be copied to a 2nd buffer
just to turn the 0-terminated name=value pairs into \n-terminated ones.
NB: I admit that I mainly did this because it looked like a nice, simple
programming task.
A few comments:
- I'm not the maintainer, and I don't see why this got sent here.
- There's no reason to factor out print_event_if, and the code it replaced
is clearer and more concise.
There's a very good reason to do that, namely, it's a separate task
working with its own set of variables, even in the original code. And
I don't see it as *a* separate task; it's
- reformat the message
- decide whether to print the message
- print the message
which is two or three separate tasks, combined because none of them are
working solely with their own set of variables.
something which boasts of its light-weightness should keep rescanning
should *not* is what you intended to write, I presume?
the same data over and over again just because that's what the standard
C library str*-functions will do when used naively or in situations
they're not well-suited for, eg
for (i = 0, olen = 0; i len; i += slen + 1) {
slen = strlen(buf+i);
if (!slen || !strchr(buf+i, '='))
continue;
At this point, what would really be needed is a function which returns
a pointer to the next '=' or '\000' but C doesn't provide one.
memchr(buf+i, '\0', sizeof(buf)-i) doesn't work if you want the next char
matching ('=' || '\0'). strchrnul() does what you're asking about, but
isn't portable (GNU only).
A bigger problem is that you need to keep track of the size of the remaining
part of the buffer.
If memcspn() existed, it would be the perfect solution, but it doesn't.
slen = strlen(), then strchr() over the same memory, does involve running
over the same memory twice, but honestly:
you're complaining about going back over 8 bytes of memory?
That's about the longest that a netlink message from the kernel will go
before you hit an '=', unless you're dealing with the start of a packet.
And that's pretty short.
Thanks,
Isaac Dunham
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automount, mount, and USB sticks
I am certain there is a way of solving this automounting problem (if I may call it that) cleanly, without the use of either of them. :-) Yes, a daemon running as root could do it. And if the daemon does nothing but observe inotify and dmesg, perhaps check a fifo for devices to be mounted/unmounted (with complete cleansing of that fifo's information) and perform a mount command, I imagine we could get a handle on security. Ther is still /proc/sys/kernel/hotplug nik -- Please do not email me anything that you are not comfortable also sharing with the NSA. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automount, mount, and USB sticks
On Thu, Jul 30, 2015 at 12:40:33AM +0200, Didier Kryn wrote: I don't understand the preventions against sudo. It is just up to the administrator to take care, like for everything. Wether execution of the command is allowed by sudo, by a setuid bit or by policykit does not change the result. Sudo is simply the most versatile method to allow/disallow actions, IMHO far easier to configure than policykit. Don't forget that allowed commands may (should) be specified with their absolute path, therefore bypassing PATH. It is better than having a specialized daemon for this and that, because it keeps everything configured in one well known file. In the case of mounting usb sticks, this applies to a personal computer, where the owner is also the administrator. For conveniency, a limited list of actions may be allowed without password, like mounting a usb key. I'm not sure where in the discussion this fits, but I thought I'd mention it here: Permitting all mount invocations via sudo does have a potential security hole if your mount implementation supports FUSE, as you can run an arbitrary command by specifying the mount type. I don't think that sudo does the necessary steps to block this. If you use a wrapper script, you can make it automatically determine the type and run ntfs-3g if appropriate, then allow sudo to run that. If you use a C wrapper, you can do that and make it suid. HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automount, mount, and USB sticks
On 29/07/2015 19:44, Jaromil wrote: IMHO the bigger barrier to this is not having a string parsing code (or basic grammar) that is security oriented, I mean hardened to run as root and handle corner cases The tool I linked does no parsing at all. The user gives the end of the command line she wants to run, but the start of the command line is fixed at daemon start time. One daemon per start of command line; you can have hundreds of those if needed, because each instance uses very little memory (max 2 pages of private dirty stack, no heap). most code out there has too many features and is too ambitions to fulfill such a simple task I have a lot of tools that fulfill simple tasks, specifically made to address these kinds of problems. When you're done with your priorities - releasing Devuan 1.0 -, let's talk. I think I speak for most people here when I say we dislike the quantity of undocumented daemons running on on gnu/Linux desktop nowadays and I hope we can trim that down with Devuan The real sticking point in what you just wrote is undocumented. I think most people wouldn't mind a pandemonium on their machine IF they knew exactly what daemon is doing what, how many resources a daemon consumes, and how to disable the ones they don't need. -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] xargs guide
Hi all, xargs is a gender-changer type program that adapts one program's stdout to the next program's command line arguments. It's extremely handy for shell scripting, but it can be tricky. I've written a short guide for xargs that shows how to get around the usual xargs landmines: http://www.troubleshooters.com/linux/xargs.htm Hope you like it. SteveT Steve Litt July 2015 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automount, mount, and USB sticks
Le 28/07/2015 21:17, Hendrik Boom a écrit : Once, an icon for the device would appear on my screen that I could click to mount. This feature is working very well with xfce4 on Debian Wheezy. If the partitions on the USB disk are labelled, they get mountpoints by the label, on /media. This is exactly the behaviour I like. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automount, mount, and USB sticks
Hi, Steve Litt wrote on 29/07/2015 at 06:25 CEST: [...] Meanwhile, as far as I can see, their entanglement with polkit does nothing more than my idea about sudo. Does anyone see any reason why polkit should be assumed more secure than sudo? I don't know about polkit, but sudoers(5) is a mess, and for something else than a quickhack (I know, they last longest!), I would not entrust sudo(8) with a mount(8) invocation before serious consideration. Commandline executables' option surfaces are so convoluted and the programs have so many features that, for example, I can not immediately tell if it is possible to launch a shell via invocation of mount(8) or not. [...] Kind regards, T. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] A better default windows manager
On Sun, Jul 26, 2015 at 11:18:58PM -0400, Steve Litt wrote:
You can roll your own automount with one day's work using inotify-wait,
dmesg, sudo, lsblk, and the mount command. Works without X or window
manager. Heck, I'll do it myself if more than 20 people want it.
Or you can do it with mount, sudo, sh, and nlmon (http://git.r-36.net/nlmon).
Here's a demo of how to do it:
./nlmon -f block | { \
while read LINE
do
case x$LINE in
(xACTION=*|xDEVNAME=*) eval $LINE
;;
(x) if [ x$DEVNAME != x ]
then
echo automount $DEVNAME $ACTION
fi
unset ACTION DEVNAME
;;
esac
done
}
Only instead of echo automount ..., you would use your mount helper
(pmount, sudo mount, ...)
nlmon reqires only libc-dev, linux-libc-dev, and a working make and
compiler.
I will note, however, that you currently need to make one small change
in nlmon.c before compiling it:
change write(0, to write(1,.
This example can be run from a user session; if one prefers, the automounter
could be replaced with a popup or anything else.
HTH,
Isaac Dunham
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automount, mount, and USB sticks
Le 29/07/2015 14:15, Hendrik Boom a écrit : On Wed, Jul 29, 2015 at 10:08:56AM +0200, Didier Kryn wrote: Le 28/07/2015 21:17, Hendrik Boom a écrit : Once, an icon for the device would appear on my screen that I could click to mount. This feature is working very well with xfce4 on Debian Wheezy. If the partitions on the USB disk are labelled, they get mountpoints by the label, on /media. This is exactly the behaviour I like. Yes. On wheezy. Which does suggest that we should be able to resurrect old code and make it work on devual jessie. But I see that people are already discussing how this should happen using new code such as vdev. I understand from other posts that libudev-compat, which comes with vdev, will suffice. However I think it would be better for this application to be triggered by inotify and find information on the partitions from libblkid. I don't really know what libudev provides; my understanding is that it is second hand information and services, just for the sake to provide yet another interface. Instead both inotify and libblkid are plain Linux tools. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automount, mount, and USB sticks
On Wed, 29 Jul 2015 10:21:37 +0200 tilt! t...@linuxfoo.de wrote: Hi, Steve Litt wrote on 29/07/2015 at 06:25 CEST: [...] Meanwhile, as far as I can see, their entanglement with polkit does nothing more than my idea about sudo. Does anyone see any reason why polkit should be assumed more secure than sudo? I don't know about polkit, but sudoers(5) is a mess, This is exactly my point. Every last problem of sudo is taken seriously, while everyone seems to give polkit a pass. Maybe there's another way around this: A daemon, running as root, that senses something being plugged in, and mounts it. Since it's running as root, no sudo or polkit needed. And, a facility by which a normal user can tell this daemon to mount or unmount some specific thing. SteveT Steve Litt July 2015 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automount, mount, and USB sticks
On Wed, Jul 29, 2015 at 10:08:56AM +0200, Didier Kryn wrote: Le 28/07/2015 21:17, Hendrik Boom a écrit : Once, an icon for the device would appear on my screen that I could click to mount. This feature is working very well with xfce4 on Debian Wheezy. If the partitions on the USB disk are labelled, they get mountpoints by the label, on /media. This is exactly the behaviour I like. Yes. On wheezy. Which does suggest that we should be able to resurrect old code and make it work on devual jessie. But I see that people are already discussing how this should happen using new code such as vdev. U have no idea which method is better. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automount, mount, and USB sticks
- Original Message - From: kpb k...@sohcahtoa.org.uk Rob Owens row...@ptd.net wrote: Before I stopped using Jessie, I had USB mounting working with the spacefm file manager and either udevil or pmount to handle the removable devices. Let me know if anybody wants instruction on that. -Rob Hello Rob I'd appreciate an outline of the way you got pmount to talk to your file manager if you have your notes written up already and it is not too onerous. I'm not on a Jessie system now, but I have access to its config files. So some of this is from memory: Spacefm has the ability to use several different methods to mount removable media. If you install either pmount or udevil, it can use them. By default, I believe it automatically chooses which method it wants to use, based on what you have installed. If you want to force it to use pmount, go to Spacefm's Devices menu, Settings, Device Handlers. Click on the Default device handler, and uncomment the pmount lines in the Mount and Unmount sections. pmount and udevil have their own differing conventions for where to mount the removable media. For udevil, at least, that can be configured (allowed_media_dirs in udevil.conf). On Jessie, I have noticed that some applications don't properly detect the mounted removable media if it's mounted this way. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774871 By the way, I just discovered there is something called pmount-gui, which is not available in Debian. It provides a very basic gui for pmount. In my quick testing, I was able to mount a usb stick, but I see no option to unmount. -Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automount, mount, and USB sticks
Hi Steve, Steve Litt wrote on 29/07/2015 at 15:35 CEST: On Wed, 29 Jul 2015 10:21:37 +0200 Steve Litt wrote on 29/07/2015 at 06:25 CEST: [...] Meanwhile, as far as I can see, their entanglement with polkit does nothing more than my idea about sudo. Does anyone see any reason why polkit should be assumed more secure than sudo? I don't know about polkit, but sudoers(5) is a mess, This is exactly my point. Every last problem of sudo is taken seriously, while everyone seems to give polkit a pass. I am not everyone :-D and polkit gets no pass from me, I just don't have it installed, because it more tends to get in my way more than to solve problems I actually have. I just fail to accept sudo as a superior alternative. The trouble is not so much with the way sudo is configured (I've seen worse), but with the fact that it privileges users' *commandlines*, which, at least for this specific application (to perform mounting) I consider a useless and potentially harmful indirection. I am certain there is a way of solving this automounting problem (if I may call it that) cleanly, without the use of either of them. :-) Kind regards, T. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automount, mount, and USB sticks
Every last problem of sudo is taken seriously? Did you know that if someone has limited access, e.g. the right to install standard packages, then it is easy to leverage that to get complete access. Various packages run programs in $PATH as root, Firefox comes to mind, so just prepare $PATH and sudo apt-get install firefox. Sudo leaves the user's $PATH and the rest is just a matter of finding the right exploit. Was open for years, may still be open. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automount, mount, and USB sticks
On Wed, 29 Jul 2015 16:35:56 +0200 a...@gulbrandsen.priv.no wrote: Every last problem of sudo is taken seriously? Did you know that if someone has limited access, e.g. the right to install standard packages, then it is easy to leverage that to get complete access. Various packages run programs in $PATH as root, Firefox comes to mind, so just prepare $PATH and sudo apt-get install firefox. Sudo leaves the user's $PATH and the rest is just a matter of finding the right exploit. Was open for years, may still be open. I repeat my question: Do you have first hand knowledge indicating that polkit is any safer? SteveT Steve Litt July 2015 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] nlmon (was: A better default windows manager)
Isaac Dunham ibid...@gmail.com writes:
Or you can do it with mount, sudo, sh, and nlmon (http://git.r-36.net/nlmon).
Using poll to wait for a message followed by recvmsg for reading it
offers (in absence of a timeout) no advantages over just doing a
blocking recv. Since this code neither uses control messages nor looks
at the returned flags, it can use recvfrom instead of the (more
complicated) recvmsg. Considering that it checks for message buffer
overflow via len = sizeof(buf), the MSG_TRUNC flag should probably be
used to make the kernel return the real size in case a datagram was
truncated. Lastly, the message doesn't have to be copied to a 2nd buffer
just to turn the 0-terminated name=value pairs into \n-terminated ones.
NB: I admit that I mainly did this because it looked like a nice, simple
programming task.
diff --git a/nlmon.c b/nlmon.c
index 7339f74..8e965fe 100644
--- a/nlmon.c
+++ b/nlmon.c
@@ -53,15 +53,50 @@ usage(void)
die(usage: %s [-h] [-kl] [-f subsystem]\n, argv0);
}
+void
+print_event_if(char *subsys, char *p, int len)
+{
+ char *s, *e, *sep;
+ char *start;
+
+ start = p;
+ e = p + len;
+
+ /* find start of name=value pairs */
+ while (++p e *p != '=')
+ if (!*p) start = s = p + 1;
+ if (p == e) return;
+
+ do {
+ sep = p;
+
+ /* skip to end of parameter */
+ do ++p; while (p e *p);
+ if (p == e) return;
+
+ if (subsys strncmp(SUBSYSTEM, s, sep - s) == 0) {
+ if (strcmp(sep + 1, subsys) != 0) return;
+ subsys = NULL;
+ }
+
+ *p = '\n';
+
+ /* find next = */
+ s = ++p;
+ while (p e *p != '=') ++p;
+ } while (p e);
+
+ *p++ = '\n';
+ write(1, start, p - start);
+}
+
int
main(int argc, char *argv[])
{
struct sockaddr_nl nls, cnls;
- struct pollfd fds;
- struct msghdr hdr;
- struct iovec iov;
- char buf[4097], obuf[4098], *subsystem;
- int i, len, olen, slen, showudev, showkernel;
+ socklen_t cnlslen;
+ char buf[4097], *subsystem;
+ int len, showudev, showkernel, sk;
showkernel = 1;
showudev = 1;
@@ -93,9 +128,8 @@ main(int argc, char *argv[])
* messages in userspace.
*/
- fds.events = POLLIN;
- fds.fd = socket(PF_NETLINK, SOCK_DGRAM, NETLINK_KOBJECT_UEVENT);
- if (fds.fd 0)
+ sk = socket(PF_NETLINK, SOCK_DGRAM, NETLINK_KOBJECT_UEVENT);
+ if (sk 0)
edie(socket);
/*
@@ -104,20 +138,15 @@ main(int argc, char *argv[])
* enough buffer.
*/
- if (bind(fds.fd, (void *)nls, sizeof(nls)))
+ if (bind(sk, (void *)nls, sizeof(nls)))
edie(bind);
- buf[sizeof(buf)-1] = '\0';
- while (poll(fds, 1, -1) -1) {
- iov.iov_base = buf;
- iov.iov_len = sizeof(buf);
- memset(hdr, 0, sizeof(hdr));
- hdr.msg_iov = iov;
- hdr.msg_iovlen = 1;
- hdr.msg_name = cnls;
- hdr.msg_namelen = sizeof(cnls);
-
- len = recvmsg(fds.fd, hdr, 0);
+ while (1) {
+ buf[sizeof(buf)-1] = '\0';
+ cnlslen = sizeof(cnls);
+ len = recvfrom(sk, buf, sizeof(buf), MSG_TRUNC,
+ (struct sockaddr *)cnls, cnlslen);
+
if (len 0) {
if (errno == EINTR)
continue;
@@ -126,40 +155,10 @@ main(int argc, char *argv[])
if (len 32 || len = sizeof(buf))
continue;
- if (!memcmp(buf, libudev, 8)) {
- if (!showudev)
- continue;
- } else {
- if (!showkernel)
- continue;
-
- /*
-* Kernel messages should be from root.
-*/
- if (cnls.nl_pid 0)
- continue;
- }
-
- for (i = 0, olen = 0; i len; i += slen + 1) {
- slen = strlen(buf+i);
- if (!slen || !strchr(buf+i, '='))
- continue;
- if (subsystem !strncmp(buf+i, SUBSYSTEM=, 10)
-!strstr(buf+i+10, subsystem)) {
- olen = 0;
- break;
- }
-
- snprintf(obuf+olen, sizeof(obuf)-olen-2,
- %s\n, buf+i);
- olen += slen + 1;
- }
- if (olen 0) {
- obuf[olen] = '\n';
-
Re: [DNG] automount, mount, and USB sticks
On Wed, 29 Jul 2015 08:18:33 +0100 kpb k...@sohcahtoa.org.uk wrote: and being able to add *GUI initiated* mount/unmount (say by clicking on a volume name in the file manager) would be a real advance over pmount in a terminal window. The preceding is a matter of opinion and dependent on one's philosophy. I'd say performing an action on the command line is a real advance over doing it in a gui: * You can do it without X running. * You can do it over no-X ssh. * It's simpler. * You don't lose access to it if you change window managers or file managers. * You can put it in shellscripts. * You can *always* put a button or window in a GUI somewhere that calls the command with the right parameters, but it's very difficult to go the other direction. The preceding points are relevant not only for mounting, but for pretty much anything. Do you view the OS as commands, and the GUI as a layer over that OS, or do you view the OS as a GUI? I think Devuan needs to decide on this philosophical question, because it completely determines how things are coded. Just speaking for myself, I'd feel better if, to the extent possible, every GUI action is mapped through commands capable of being run on the command line. SteveT Steve Litt July 2015 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
