Re: [DNG] automount, mount, and USB sticks
Hendrik Boom writes: > On Thu, Jul 30, 2015 at 10:28:30AM +0100, Rainer Weikusat wrote: [sudo/ PATH] >> Also, the Debian default configuration >> contains a >> >> Defaults >> secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" >> >> which means the user PATH won't be passed on unless someone explicitly >> choses to enable it. > > So defining this secure_path means it's the PATH to be used for sudo? > and if it's not defined it defaults to PATH? Is it the same for su? According to the su man page, The value of $PATH is reset to /bin:/usr/bin for normal users, or /sbin:/bin:/usr/sbin:/usr/bin for the superuser. This may be changed with the ENV_PATH and ENV_SUPATH definitions in /etc/login.defs. > And where is this defined? /etc/sudoers ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automount, mount, and USB sticks
On Sat, 1 Aug 2015 05:13:46 -0400 Renaud (Ron) OLGIATI wrote: > If I wanted my users to use sudo, I would install them *ubuntu... :-) Wait a minute. You can't do that. * If I wanted my children to breath, I'd give them oxygen tanks. * If I wanted to spend my money, I'd buy a Testerosa. :-) 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 Thu, 30 Jul 2015 18:59:31 +0200 tilt! wrote: > Hi Jaromil! > > Jaromil wrote on 29/07/2015 at 19:44 CEST: > > [...] > > 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... > > This is how I personally see it: In an ideal environment, > there were *no* things done during regular use of a personal > computing device that required administrative permissions. It sounds to me like you guys are basically in agreement, becasuse tilt! makes his point assuming, and I quote him: "during regular use of a personal computing device" 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 Thu, 30 Jul 2015 09:18:16 -0400 (EDT) Rob Owens wrote: > Another reason not to give users wholesale access to the mount > command is that they could then 'mount -o remount,rw' any filesystem > that the administrator has mounted read-only. To protect against > this, I think you probably need something a bit more complicated than > just sudo. Of course, for a single user system, this is not a > problem. Yes! I'd like to make clear that my advocacy, or even acceptance, of automount, is for a system used as a *personal computer* by exactly one person, and that person either has the brains to know about mounting, or is ignorant enough that s/he's not going to use mount or umount for anything beyond discs and thumb drives. Automount on a server would be crazy. 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 30/07/2015 11:28, Rainer Weikusat a écrit : Didier Kryn writes: 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. According to some tests I did yesterday, sudo (at least the Debian sudo) won't allow specifying commands without a pathname so that's not an issue. But according to the manpage, the upstream sudo default policy wrt the PATH a user happens to be using when invoking sudo is "pass it one to the command executed by sudo". Should this command, in turn, execute some other command without an explicit pathname and use one of the PATH-searching functions to do so, this will effectively allow the invoking user to run any code 'as root' because he can use a PATH containing a directory with a suitably named file in it whose contents can be anything. But that's no different from any other conceivable way to trick some program running with elevated privileges on behalf of an unprivileged user into running arbitrary code, it's just a simple and obvious way to do so which doesn't require any programming (skills) and the solution is "Well, don't do that". Also, the Debian default configuration contains a Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" which means the user PATH won't be passed on unless someone explicitly choses to enable it. The upstream default PATH handling policy is not suitable for an environment where certain users are supposed to be restricted to performing specific actions with elevated privileges unless the corresponding programs don't run other programs they found in PATH but that's it. I've always used sudo on Debian and I supposed it was the same on all distros. Maybe naive... So there is this secure_path, plus a list of allowed editors (for visudo). Plus you can allow commands with absolute filenames, which discards the use of PATH, plus you can allow commands only with given arguments, and you can forbid commands with given arguments. That's a lot of possibilities. Now, if I don't secure the PATH and I allow users to run a command of my own, which is itself insecure, because it allows the use of PATH, then, sorry, I cannot accuse sudo! Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automount, mount, and USB sticks
Le 01/08/2015 17:49, Isaac Dunham a écrit : Alternately, you could write a wrapper that*always* mounts under /media, and doesn't accept -t; it just takes a device name, creates an equivalent name under /media, checks type and whether ntfs-3g is installed, and passes a suitable type to mount (or uses mount.ntfs-3g). I think that's exactly the thing which is needed: a tool dedicated to mount/umount removable medias on dynamically created/deleted mountpoints in /media, and nothing else. And this tool can be put in /usr/bin. sudo is fine to invoke it from the command line, but I'm not sure how to do when it is invoked from a mouse-click, unless the line in the sudoers file contains NOPASSWD. Of course this all is meant for a personal computer, not for a server; anyway it's useless on a server. 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 Fri, Jul 31, 2015 at 10:47:29AM +0100, Rainer Weikusat wrote: > > A daemon process should only exist because it provides some important > functionality with a real benefit for users of the system which cannot > (reasonably) be provided in some other way, eg, by starting a program to > perform a certain task on demand. Eg, there should be no daemon running > permanently to monitor device creation events which never happen in > order to create device nodes for hardware which was detected on boot and > won't go away while the system is up. And it also shouldn't be running > because every other millenium (as seen from the perspective of the > computer), someone changes the configuration of the USB(-lan): This can > perfectly well be handled with on-demand execution (and hadn't udev > eaten hotplug, I certainly wouldn't be running it). You could try mdev if you don't like udev. Devuan/Debian packaging is available at github.com/idunham/mdev git.devuan.org/idunham/mdev (builds with dpkg-buildpackage -b, no debs available yet though I'll switch them on as soon as I find out how...) Some warnings, though: * I'd suggest trying it out on a test install before your main system, for the present. If you like living dangerously and have a *plain* disk layout (no RAID, encryption), perhapps you might get away with dropping it in your main install. * Right now, you'll need to manually configure xorg.conf or at least disable input device hotplugging. Piotr Karbowski has some configuration files to take care of that in the xorg.conf.d/ directory of https://github.com/slashbeast/mdev-like-a-boss * That package has no hooks to handle LVM, encrypted partitions, or anything else odd; if you need those, you'll have to poke around and see what you can find (mdev-like-a-boss repo suggested as a starting point). 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
On Fri, Jul 31, 2015 at 07:12:05AM -0400, Steve Litt wrote: > Someone mentioned that we have too many daemons and this shouldn't be > one. If you want the thing to be *auto*mount instead of just "mount > when I tell you to, or "search for possible mounts and tell me about > them", it has to be a background process having inotify or > inotify-wait, and this would be started by the init program or process > supervisor. I (I'm the rant author, if anyone remembers) would be completely happy with these two non-auto mount commands. No need for a long-running daemon. If you remember the rant, most of the automount methods I've been treated to so far have done it wrong. I'd welcome something more explicit. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automount, mount, and USB sticks
Laurent Bercot writes:
> On 31/07/2015 11:47, Rainer Weikusat wrote:
>>
>> [example of a completely useless daemon process]
>>
>> But that's not a good reason for it being installed and running: A
>> daemon process should only exist because it provides some important
>> functionality with a real benefit for users of the system which cannot
>> (reasonably) be provided in some other way
>
> Nobody contradicts that, and in particular I don't see how this
> disagrees with my point. It's the job of the distribution to make sure
> only useful daemons are started.
>
> Giving the user the ability to gain privileges without opening a
> security hole fits my definition of "useful".
There were two points I was trying to make:
1) Users shouldn't be forced to research the origin and purpose
of strange processes suddenly appearing on some system,
followed by doing whatever is necessary to get rid of them in
case they consider them useless for them. Eg, I meanwhile
have an apt.conf file stating
APT {
Install-Recommends "false";
};
because I grew tired of keeping to deinstall the avahi "LAN
party" daemon whenever I was installing one of the bazillions
of packages whose maintainers 'recommended' it to my
attention. If I need this, I'll install it, and for as long
as I don't, I don't want it to be running, documentation and
frugal use of resources notwithstanding.
2) Something which can be implemented without a continuously
running process should be implemented in this way.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automount, mount, and USB sticks
On Sat, Aug 01, 2015 at 08:49:55AM -0700, Isaac Dunham wrote: > On Thu, Jul 30, 2015 at 10:39:22PM +0200, Didier Kryn wrote: > > Isaac, your comment suggests me two questions: > > One: is it really possible to mount a Fuse filesystem with 'mount' ? I > > thought it could only be done with 'fusermount'. > > Yes, it is possible. > I've used sshfs in fstab, set up so I could "mount ~/remote-site". Presumably the fstab entry specified sshfs. Aren't the restrictions that sshfs itself imposes already enough? It requires that ~/remote_site be owned by the user executing sshfs, and also that the user have the correct password to log in to the remote system. Not even root can access an sshfs file system that I've mounted as myself. > > > Two: if the idea is not to allow '/sbin/mount' in sudo, but to allow a > > smart wrapper, is there still an issue? > > If the wrapper is smart enough, there isn't. > Of course, that qualifier is a big one. > > If I were doing it, I would > * disallow -t fuse (if it's set up in /etc/fstab so as to allow users, > that's OK) > Perhaps one could even disallow "-t" entirely, and rely on autodetection. > * disallow mounting at any directory not owned by or writeable by the user. > Perhaps this could be moderated by ...except that any user can mount > under /media, if they're not overmounting. sshfs does this itself. At present, what defines which user file systems can be a fuser file system? Perhaps it's the user file systems themselves that should enforce the security restrictions on their use, as I understand sshfs to do now. -- hendrik ___ 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 10:28:30AM +0100, Rainer Weikusat wrote: > Didier Kryn writes: > > 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. > > According to some tests I did yesterday, sudo (at least the Debian sudo) > won't allow specifying commands without a pathname so that's not an > issue. But according to the manpage, the upstream sudo default policy > wrt the PATH a user happens to be using when invoking sudo is "pass it > one to the command executed by sudo". Should this command, in turn, > execute some other command without an explicit pathname and use one of > the PATH-searching functions to do so, this will effectively allow the > invoking user to run any code 'as root' because he can use a PATH > containing a directory with a suitably named file in it whose contents > can be anything. > > But that's no different from any other conceivable way to trick some > program running with elevated privileges on behalf of an unprivileged > user into running arbitrary code, it's just a simple and obvious way to > do so which doesn't require any programming (skills) and the > solution is "Well, don't do that". Also, the Debian default configuration > contains a > > Defaults > secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" > > which means the user PATH won't be passed on unless someone explicitly > choses to enable it. So defining this secure_path means it's the PATH to be used for sudo? and if it's not defined it defaults to PATH? Is it the same for su? And where is this defined? -- hendrik ___ 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 10:39:22PM +0200, Didier Kryn wrote: > Le 30/07/2015 01:09, Isaac Dunham a écrit : > >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. > > > Isaac, your comment suggests me two questions: > One: is it really possible to mount a Fuse filesystem with 'mount' ? I > thought it could only be done with 'fusermount'. Yes, it is possible. I've used sshfs in fstab, set up so I could "mount ~/remote-site". > Two: if the idea is not to allow '/sbin/mount' in sudo, but to allow a > smart wrapper, is there still an issue? If the wrapper is smart enough, there isn't. Of course, that qualifier is a big one. If I were doing it, I would * disallow -t fuse (if it's set up in /etc/fstab so as to allow users, that's OK) Perhaps one could even disallow "-t" entirely, and rely on autodetection. * disallow mounting at any directory not owned by or writeable by the user. Perhaps this could be moderated by ...except that any user can mount under /media, if they're not overmounting. I suppose that the second point forces use of a suid helper, rather than the use of sudo. Alternately, you could write a wrapper that *always* mounts under /media, and doesn't accept -t; it just takes a device name, creates an equivalent name under /media, checks type and whether ntfs-3g is installed, and passes a suitable type to mount (or uses mount.ntfs-3g). 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
IMHO automount for desktop is a helper for a user running some X session. Usually that means that a single person is using this system. So make him a helper which can do automount/autorun etc which helps him on a daily basis. Helps him not the admin of the system. A simple one which is a helper, not a policeman/guardian/supervisor who monitors and authorizes user's actions. I understand that sysadmin of a server with many different users will not install such thing on his system, cause this make be used to break security. If the tool is simple enouth to do limited number of actions, it can be audited and secured and maybe some day it will be accepted even on multiuser systems. There is also automount for a sysadmin on a multiuser server, with no X sessions, which makes life of sysadmin easier. Same name two different targets. Same tool might be used for both, but I personally would prefer to have two different ones. For my X session perfect tool is a panel application listing available devices with it's current/future mount point, disk size/usage, allowing mount/unmount/eject by mouse click. It may have a checkboxes to automount/autorun new devices. I will not use it, but I do not care if it is there if it is not turned on or it can be easily turned off. It may list entries from fstab, autodiscoverd devices or even also from it's own config file for those who want to put more complicated mount/umount scripts. For anything more complex su/sudo is better (for me). I understand that there is a closed list of actions every user will have to perform on any system while running interactive graphic session. As such user would expect to have helpers for such actions easily available (perfectly on desktop or as visible panel applets). Later one will learn and choose the tools one wants and the way one want to use them. And a fixed set of simple helpers visible on desktop/panel would make a life easier. On Thu, Jul 30, 2015 at 3:18 PM, Rob Owens wrote: > - Original Message - >> From: "Isaac Dunham" >> 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. >> > Another reason not to give users wholesale access to the mount command is that > they could then 'mount -o remount,rw' any filesystem that the administrator > has mounted read-only. To protect against this, I think you probably need > something a bit more complicated than just sudo. Of course, for a single > user system, this is not a problem. > > -Rob > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automount, mount, and USB sticks
If I wanted my users to use sudo, I would install them *ubuntu... Cheers, Ron. -- Schroedinger thought inside the box. -- http://www.olgiati-in-paraguay.org -- ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automount, mount, and USB sticks
On 31/07/2015 11:47, Rainer Weikusat wrote: But that's not a good reason for it being installed and running: A daemon process should only exist because it provides some important functionality with a real benefit for users of the system which cannot (reasonably) be provided in some other way Nobody contradicts that, and in particular I don't see how this disagrees with my point. It's the job of the distribution to make sure only useful daemons are started. Giving the user the ability to gain privileges without opening a security hole fits my definition of "useful". -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automount, mount, and USB sticks
Le 30/07/2015 01:30, Laurent Bercot a écrit : 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. Yes, it is mostly a question of book-keeping, and maybe supervision :-) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automount, mount, and USB sticks
If I was about to make a friendly for me Desktop, I would provide a system service/library/daemon/whatever, where every application while installing on the system could register (during installation) a set of commands to be executed later with root privileges. And later ask for execution of those commands, assuming that the service will take care of communicating with the user and authorizing such request. So during application installation I could do audit if I want. This way every application designed for that framework could be programmed standard way, and Iwould have to authenticate once a while (like sudo does). Having control what is executed with root privileges. Gives freedom to everybody - developer to desing the set of privileged commands/application flow/etc, the admin/user to audit/use it. Now, every application may solve this in its own different way. Systemd in opposite, gives fixed set of commands, and forces all to us it. -- regards piotr On Thu, 30 Jul 2015 01:30:36 +0200, Laurent Bercot wrote: 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. -- Using Opera's mail client: http://www.opera.com/mail/ ___ 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 19:44:44 +0200 Jaromil wrote: > 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 The first word is parsed to be either mount or umount. Or even m or u. The second word is a valid device name, and must be in the /dev tree. There are no other words. Someone mentioned that we have too many daemons and this shouldn't be one. If you want the thing to be *auto*mount instead of just "mount when I tell you to, or "search for possible mounts and tell me about them", it has to be a background process having inotify or inotify-wait, and this would be started by the init program or process supervisor. 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 30/07/2015 01:09, Isaac Dunham a écrit : 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. Isaac, your comment suggests me two questions: One: is it really possible to mount a Fuse filesystem with 'mount' ? I thought it could only be done with 'fusermount'. Two: if the idea is not to allow '/sbin/mount' in sudo, but to allow a smart wrapper, is there still an issue? Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automount, mount, and USB sticks
Didier Kryn writes: > 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. According to some tests I did yesterday, sudo (at least the Debian sudo) won't allow specifying commands without a pathname so that's not an issue. But according to the manpage, the upstream sudo default policy wrt the PATH a user happens to be using when invoking sudo is "pass it one to the command executed by sudo". Should this command, in turn, execute some other command without an explicit pathname and use one of the PATH-searching functions to do so, this will effectively allow the invoking user to run any code 'as root' because he can use a PATH containing a directory with a suitably named file in it whose contents can be anything. But that's no different from any other conceivable way to trick some program running with elevated privileges on behalf of an unprivileged user into running arbitrary code, it's just a simple and obvious way to do so which doesn't require any programming (skills) and the solution is "Well, don't do that". Also, the Debian default configuration contains a Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" which means the user PATH won't be passed on unless someone explicitly choses to enable it. The upstream default PATH handling policy is not suitable for an environment where certain users are supposed to be restricted to performing specific actions with elevated privileges unless the corresponding programs don't run other programs they found in PATH but that's it. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automount, mount, and USB sticks
Hi Jaromil! Jaromil wrote on 29/07/2015 at 19:44 CEST: [...] 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... This is how I personally see it: In an ideal environment, there were *no* things done during regular use of a personal computing device that required administrative permissions. Inversion of argument: The more operations occurring during regular operation of a system require administrative rights, the more flawed the system is, be it, because it has a wrong concept of what "administrative" is or because it fails to secure its operation properly, and thus, to gain plausible deniability, confronts the user with "this is dangerous, enter a superuser password, abandon all hope" in trivial usage scenarios (see also note [1] for an example). Having said that, I agree that attaching ephemeral, untrusted storage media into the filesystem hierarchy is a security- critical operation. Doing so must be performed as consciously as possible, security implications must have been considered and precautions must have been taken. In the light of this, isn't it preferable to have this system behavior of "automounting" performed by a dedicated service that manifests itself as an unmistakably perceivable process instead of burying it in some cryptic XML or Javascript configuration of a policy management subsystem? And, you may disagree, but sudo to me is "a rootshell where every commandline is prefixed with the string 'sudo '". Is that a better solution? Kind regards, T. Note [1]: Example: Installing new software via "packages" requires superuser permissions, because all those packages are entangled into one big bulk of a system called the "distribution", and messing with what's installed voids the warranty. ;-) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automount, mount, and USB sticks
Laurent Bercot writes:
[...]
>> 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.
I beg to differ here. Assuming the following little program:
#include
#include
int main(void)
{
while (1) {
if (fork() != 0) exit(0);
sleep(2);
}
return 0;
}
If this is running on some system, it will keep a purposeless process
available in a process listing which is somewhat difficult to kill. It
consumes basically no resources, however, and it could be documented as
avalo
This daemon reproduces itself in a controlled way, consuming
minimal resources. Keep one around and you'll never have to feel
alone in the wilderness.
Most people probably wouldn't care for something like this if it got
installed as side-effect of installing some package they wanted to use
and if the system started it automatically because the cost of getting
rid of it is much higher than any real damage it does. Should they
notice it, they'd probably have a short moment of "Incompetent
fuckers. They simply can't do this without an ever-increasing amount of
processes with silly names whose purpose I don't really understand!" and
then forget about it without ever bothering to look for corresponding
documentation, let alone read it.
But that's not a good reason for it being installed and running: A
daemon process should only exist because it provides some important
functionality with a real benefit for users of the system which cannot
(reasonably) be provided in some other way, eg, by starting a program to
perform a certain task on demand. Eg, there should be no daemon running
permanently to monitor device creation events which never happen in
order to create device nodes for hardware which was detected on boot and
won't go away while the system is up. And it also shouldn't be running
because every other millenium (as seen from the perspective of the
computer), someone changes the configuration of the USB(-lan): This can
perfectly well be handled with on-demand execution (and hadn't udev
eaten hotplug, I certainly wouldn't be running it).
___
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: "Isaac Dunham" > 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. > Another reason not to give users wholesale access to the mount command is that they could then 'mount -o remount,rw' any filesystem that the administrator has mounted read-only. To protect against this, I think you probably need something a bit more complicated than just sudo. Of course, for a single user system, this is not a problem. -Rob ___ 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
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
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 wrote: >On Wed, 29 Jul 2015 17:07:32 +0200 >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. :-) > >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] 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 Wed, 29 Jul 2015 18:41:36 +0200 Laurent Bercot 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] automount, mount, and USB sticks
On Wed, 29 Jul 2015 11:04:22 -0400 (EDT) Rob Owens 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 ___ 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! 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] automount, mount, and USB sticks
On 29/07/2015 18:03, tilt! wrote: My estimate is that such daemon was not resource hungry: Actually, I'm talking about a daemon consuming entirely negligible resources, performing no polling at all, only reacting to an external command performed either manually or via the hotplug helper. 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. So I'm just putting the link to the mechanism up there, and mentioning that sudo is a solved problem. Now, policy is up to you guys. -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
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
Arnt Gulbrandsen 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 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 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
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
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
- Original Message - > From: "kpb" > Rob Owens 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
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
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 09:46:18 -0400 Steve Litt wrote: > 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 That is a really interesting way of looing at things, thanks for the mental prompt. How would you deal with providing notifications to a GUI layer if present? Cheers -- keithpeter ___ 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 08:18:33 +0100 kpb 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
Re: [DNG] automount, mount, and USB sticks
On Wed, 29 Jul 2015 10:21:37 +0200 tilt! 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
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, 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
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] 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
On Tue, 28 Jul 2015 16:26:22 -0400 (EDT) Rob Owens 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. My 'hobby' project is at http://sohcahtoa.org.uk/osd.html 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. I recollect that SpaceFM also comes with an image viewer and other additional programs so might be a good choice for a light system. Everyone: On the general subject of mounting there is the xfce4-mount-plugin package that I recollect using on an OpenBSD install before I turned to the toad daemon with all the dbus gubbins on that platform. I could use it to mount/unmount sticks I recollect but it was very abrupt (little confirmation of actions and no back out). Thanks -- keithpeter ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automount, mount, and USB sticks
On Tue, Jul 28, 2015 at 11:09 PM, James Powell wrote: > Eventually, and I kinda realized this, work may be needed to write a > udisks replacement for vdev that can work off vdev without loosing > functionality to udisks using applications and file managers, especially > for non-Linux systems. > > Nothing fancy, but as long as it works and allows for some level of > control for admins, I don't have a problem with it. > > Thoughts? > If all udisks2 needs from the device manager is libudev (or libgudev), then we should be good to go as-is. Libgudev should work unmodified with libudev-compat. However, replacing udisks[2] with a suite of simple setuid or setgid programs that implement the equivalent functionality might be a better long-term solution. It would be much easier to hook into a GUI, for example, and if done right, it would remove the need for polkit and dbus integration. -Jude -- > From: Hendrik Boom > Sent: 7/28/2015 7:45 PM > To: dng@lists.dyne.org > Subject: Re: [DNG] automount, mount, and USB sticks > > On Tue, Jul 28, 2015 at 01:08:26PM -0700, Gregory Nowak wrote: > > On Tue, Jul 28, 2015 at 03:17:11PM -0400, Hendrik Boom wrote: > > > Of course I have to guess whether the device has > > > been plugged in as /dev/sdb, or /dev/sde, or whatever. In case of > > > (frequent) doubt, I switch to a root console with control-alt-F1 and a > > > login, unplug the device, and plug it in again. It will the tell me > > > after a while, that a new device has been inserted, and tell me what > > > /dev/sd* name it has dynamically installed. I end up, as root, > > > mounting the device with root as the owner. It's usually a USB stick > > > with one of the ubiquitous Microsoft file systems used on USB sticks, > > > and all the files can be read or writen by root only. > > > > There is a much easier way. Instead of switching consoles and > > guessing, just plug the device in, and look at the last screen full of > > the output from dmesg. > > Yes, that would have been easier. > > > Also, if you're mounting on your own laptop, it > > will usually have one hd, /dev/sda. When you plug in a usb device, it > > will probably have /dev/sdb. If you unplug it, and plug in the same > > device, or plug in another stick, it will probably have /dev/sdb > > still. > > For whatever reason, there was a time when it kept picking new letters > if I umounted the stick, took it ouot, and put another in. Maybe there > was a bug somewhere then? But I could not rely on it always being > /dev/sdb. > > > So, you could just put a line in /etc/fstab which will allow a > > normal user to mount /dev/sdb1 for example to whatever directory you > > want. All you would have to do as a normal user is to type: > > mount /dev/sdb1 > > after plugging in the drive, and you should be able to find its' > > contents under whatever directory you specified in fstab. > > Truth is, I no longer trust it to be consistent. > > -- hendrik > > > > > Greg > > > > > > -- > > web site: http://www.gregn.net > > gpg public key: http://www.gregn.net/pubkey.asc > > skype: gregn1 > > (authorization required, add me to your contacts list first) > > If we haven't been in touch before, e-mail me before adding me to your > contacts. > > > > -- > > Free domains: http://www.eu.org/ or mail dns-mana...@eu.org > > ___ > > Dng mailing list > > Dng@lists.dyne.org > > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automount, mount, and USB sticks
On Tue, 28 Jul 2015 20:09:06 -0700 James Powell wrote: > > From: Hendrik Boom<mailto:hend...@topoi.pooq.com> > Sent: 7/28/2015 7:45 PM > To: dng@lists.dyne.org<mailto:dng@lists.dyne.org> > Subject: Re: [DNG] automount, mount, and USB sticks > > On Tue, Jul 28, 2015 at 01:08:26PM -0700, Gregory Nowak wrote: > > On Tue, Jul 28, 2015 at 03:17:11PM -0400, Hendrik Boom wrote: > > > Of course I have to guess whether the device has > > > been plugged in as /dev/sdb, or /dev/sde, or whatever. In case of > > > (frequent) doubt, I switch to a root console with control-alt-F1 > > > and a login, unplug the device, and plug it in again. It will > > > the tell me after a while, that a new device has been inserted, > > > and tell me what /dev/sd* name it has dynamically installed. I > > > end up, as root, mounting the device with root as the owner. > > > It's usually a USB stick with one of the ubiquitous Microsoft > > > file systems used on USB sticks, and all the files can be read or > > > writen by root only. > > > > There is a much easier way. Instead of switching consoles and > > guessing, just plug the device in, and look at the last screen full > > of the output from dmesg. > > Yes, that would have been easier. > > > Also, if you're mounting on your own laptop, it > > will usually have one hd, /dev/sda. When you plug in a usb device, > > it will probably have /dev/sdb. If you unplug it, and plug in the > > same device, or plug in another stick, it will probably > > have /dev/sdb still. > > For whatever reason, there was a time when it kept picking new letters > if I umounted the stick, took it ouot, and put another in. Maybe > there was a bug somewhere then? But I could not rely on it always > being /dev/sdb. > > > So, you could just put a line in /etc/fstab which will allow a > > normal user to mount /dev/sdb1 for example to whatever directory you > > want. All you would have to do as a normal user is to type: > > mount /dev/sdb1 > > after plugging in the drive, and you should be able to find its' > > contents under whatever directory you specified in fstab. > > Truth is, I no longer trust it to be consistent. > > -- hendrik > > > > > Greg JAMES POWELL SAID > Eventually, and I kinda realized this, work may be needed to write a > udisks replacement for vdev that can work off vdev without loosing > functionality to udisks using applications and file managers, > especially for non-Linux systems. > > Nothing fancy, but as long as it works and allows for some level of > control for admins, I don't have a problem with it. > > Thoughts? JAMES POWELL SAID A glimpse at https://wiki.archlinux.org/index.php/Udisks shows this udisks thing to be so thoroughly entangled with programs subsumed by systemd that it's just too much work. dbus, polkit, you have to enmesh it with how much stuff just to mount something. Just to inject some humor into it, see this section: https://wiki.archlinux.org/index.php/Udisks#inotify Yeah, that's right: Arch is recommending that the actual plug-in detection be done with inotify, the isolated-from-systemd that I was going to use for my automounter if I got 20 people and Jude is using to replace part of udev. 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? And dbus? The only reason I can think of for dbus is so our good friends at Freedesktop.Org can have their desktop environment can phone in the request to unmount. About those phone-in requests via dbus: Is there any reason we can't have a program called Devuan Control Center that becomes the *real* place the user goes in order to tell the computer to unmount, reboot, poweroff, log out, etc. Seriously, why should mounting and unmounting, manually or automatically, have *anything* to do with a GUI? They're OS functions. I think rewriting udisks is a snipe hunt: we need to make a clean break, in my opinion. Otherwise we'll be forever chasing Lennart's latest great idea of the week. 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
Eventually, and I kinda realized this, work may be needed to write a udisks replacement for vdev that can work off vdev without loosing functionality to udisks using applications and file managers, especially for non-Linux systems. Nothing fancy, but as long as it works and allows for some level of control for admins, I don't have a problem with it. Thoughts? From: Hendrik Boom<mailto:hend...@topoi.pooq.com> Sent: 7/28/2015 7:45 PM To: dng@lists.dyne.org<mailto:dng@lists.dyne.org> Subject: Re: [DNG] automount, mount, and USB sticks On Tue, Jul 28, 2015 at 01:08:26PM -0700, Gregory Nowak wrote: > On Tue, Jul 28, 2015 at 03:17:11PM -0400, Hendrik Boom wrote: > > Of course I have to guess whether the device has > > been plugged in as /dev/sdb, or /dev/sde, or whatever. In case of > > (frequent) doubt, I switch to a root console with control-alt-F1 and a > > login, unplug the device, and plug it in again. It will the tell me > > after a while, that a new device has been inserted, and tell me what > > /dev/sd* name it has dynamically installed. I end up, as root, > > mounting the device with root as the owner. It's usually a USB stick > > with one of the ubiquitous Microsoft file systems used on USB sticks, > > and all the files can be read or writen by root only. > > There is a much easier way. Instead of switching consoles and > guessing, just plug the device in, and look at the last screen full of > the output from dmesg. Yes, that would have been easier. > Also, if you're mounting on your own laptop, it > will usually have one hd, /dev/sda. When you plug in a usb device, it > will probably have /dev/sdb. If you unplug it, and plug in the same > device, or plug in another stick, it will probably have /dev/sdb > still. For whatever reason, there was a time when it kept picking new letters if I umounted the stick, took it ouot, and put another in. Maybe there was a bug somewhere then? But I could not rely on it always being /dev/sdb. > So, you could just put a line in /etc/fstab which will allow a > normal user to mount /dev/sdb1 for example to whatever directory you > want. All you would have to do as a normal user is to type: > mount /dev/sdb1 > after plugging in the drive, and you should be able to find its' > contents under whatever directory you specified in fstab. Truth is, I no longer trust it to be consistent. -- hendrik > > Greg > > > -- > web site: http://www.gregn.net > gpg public key: http://www.gregn.net/pubkey.asc > skype: gregn1 > (authorization required, add me to your contacts list first) > If we haven't been in touch before, e-mail me before adding me to your > contacts. > > -- > Free domains: http://www.eu.org/ or mail dns-mana...@eu.org > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automount, mount, and USB sticks
On Tue, Jul 28, 2015 at 01:08:26PM -0700, Gregory Nowak wrote: > On Tue, Jul 28, 2015 at 03:17:11PM -0400, Hendrik Boom wrote: > > Of course I have to guess whether the device has > > been plugged in as /dev/sdb, or /dev/sde, or whatever. In case of > > (frequent) doubt, I switch to a root console with control-alt-F1 and a > > login, unplug the device, and plug it in again. It will the tell me > > after a while, that a new device has been inserted, and tell me what > > /dev/sd* name it has dynamically installed. I end up, as root, > > mounting the device with root as the owner. It's usually a USB stick > > with one of the ubiquitous Microsoft file systems used on USB sticks, > > and all the files can be read or writen by root only. > > There is a much easier way. Instead of switching consoles and > guessing, just plug the device in, and look at the last screen full of > the output from dmesg. Yes, that would have been easier. > Also, if you're mounting on your own laptop, it > will usually have one hd, /dev/sda. When you plug in a usb device, it > will probably have /dev/sdb. If you unplug it, and plug in the same > device, or plug in another stick, it will probably have /dev/sdb > still. For whatever reason, there was a time when it kept picking new letters if I umounted the stick, took it ouot, and put another in. Maybe there was a bug somewhere then? But I could not rely on it always being /dev/sdb. > So, you could just put a line in /etc/fstab which will allow a > normal user to mount /dev/sdb1 for example to whatever directory you > want. All you would have to do as a normal user is to type: > mount /dev/sdb1 > after plugging in the drive, and you should be able to find its' > contents under whatever directory you specified in fstab. Truth is, I no longer trust it to be consistent. -- hendrik > > Greg > > > -- > web site: http://www.gregn.net > gpg public key: http://www.gregn.net/pubkey.asc > skype: gregn1 > (authorization required, add me to your contacts list first) > If we haven't been in touch before, e-mail me before adding me to your > contacts. > > -- > Free domains: http://www.eu.org/ or mail dns-mana...@eu.org > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ 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: "Hendrik Boom" > Over the years the state of mounting USB drives has steadily > deteriorated on my Debian Jessie laptop. > As far as I can tell, that was caused by the introduction of systemd as a requirement for mounting removable media (at least the "standard" way of mounting removable media). 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 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automount, mount, and USB sticks
On Tue, Jul 28, 2015 at 03:17:11PM -0400, Hendrik Boom wrote: > Of course I have to guess whether the device has > been plugged in as /dev/sdb, or /dev/sde, or whatever. In case of > (frequent) doubt, I switch to a root console with control-alt-F1 and a > login, unplug the device, and plug it in again. It will the tell me > after a while, that a new device has been inserted, and tell me what > /dev/sd* name it has dynamically installed. I end up, as root, > mounting the device with root as the owner. It's usually a USB stick > with one of the ubiquitous Microsoft file systems used on USB sticks, > and all the files can be read or writen by root only. There is a much easier way. Instead of switching consoles and guessing, just plug the device in, and look at the last screen full of the output from dmesg. Also, if you're mounting on your own laptop, it will usually have one hd, /dev/sda. When you plug in a usb device, it will probably have /dev/sdb. If you unplug it, and plug in the same device, or plug in another stick, it will probably have /dev/sdb still. So, you could just put a line in /etc/fstab which will allow a normal user to mount /dev/sdb1 for example to whatever directory you want. All you would have to do as a normal user is to type: mount /dev/sdb1 after plugging in the drive, and you should be able to find its' contents under whatever directory you specified in fstab. Greg -- web site: http://www.gregn.net gpg public key: http://www.gregn.net/pubkey.asc skype: gregn1 (authorization required, add me to your contacts list first) If we haven't been in touch before, e-mail me before adding me to your contacts. -- Free domains: http://www.eu.org/ or mail dns-mana...@eu.org ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automount, mount, and USB sticks
On Tue, Jul 28, 2015 at 09:29:09AM +0100, kpb wrote: > On Tue, 28 Jul 2015 00:09:45 -0400 > Steve Litt wrote: > > > Cheer up Svante. This isn't for your corporation's web servers, it's > > for the guy with a desktop, the system's only user, a guy who already > > has root but just doesn't want to do su all the time, who just wants > > automounting to happen. > > > > That guy would be me. > > I think that xfce4 with automounting enabled will cover most of us > desktop/laptop users as a (suggested) default. xfce4 works with 2d or even > VESA video and so can work on older machines. Over the years the state of mounting USB drives has steadily deteriorated on my Debian Jessie laptop. I have done regular upgrades, have dumped gnome3 and KDE4, have removed systemd, but mostly it has been the regular updates that seem to have made things worse. Perhaps the Debian developers have managed to wrangle systemd into a form that would have worked better recently, but if so I have no knowledge of it. I have my doubts. I now use xfce. Automounting has never been satisfactory, but the the ability to mount has gone from bad to worse, auto or not. Once, it would automount, but as the wrong user. I would have to become root and unmount it, then mount it as myself. Once, an icon for the device would appear on my screen that I could click to mount. Later, I wowld have to open the file manager to get the icon on which I could open a menu that allowed me to mount. But the system would think of a place to mount it and add it to /dev. Great if I wanted to go on using the file manager to manipulate it. Not so great of I had to guess the mount point. Later, I was told I did not have the privileges needed to do the mount, but it would let me mount it anyway if I entered the root password. Nowadays, it won't even let me enter the root password to identify myself as privileged. I can only mount by opening a terminal, becoming root, and typing in a mount command. Of course I have to guess whether the device has been plugged in as /dev/sdb, or /dev/sde, or whatever. In case of (frequent) doubt, I switch to a root console with control-alt-F1 and a login, unplug the device, and plug it in again. It will the tell me after a while, that a new device has been inserted, and tell me what /dev/sd* name it has dynamically installed. I end up, as root, mounting the device with root as the owner. It's usually a USB stick with one of the ubiquitous Microsoft file systems used on USB sticks, and all the files can be read or writen by root only. Now I also use the sshfs file system on my laptop, to access most of my files, which are kept on a server at home. I mount it as myself. Then the ssh file systtem won't allow anyone other than me to read or write it. In particular, I can't execute cp from the usb stick to my home server, either as myself or as root. I end up cp'ing it to my laptop as root, chown'ing it to be mine as root, and then copyying it to the server as myself. Woe be to me if the laptop doesn't have enough temporary disk space. Of course, I suppose I could establish a second sshfs connection as root, but I really think it's getting too complicated by now. Now I realize that there are circumstances where all this is necessary for security reasons. But when it's my laptop and a USB stick my friend (one of them who uses Windows, another uses Mac, by the way) hands to me, it is crazy that I can just stick the thing into almost anybody's machine in the coffee shop and they can read and write it, but not my Jessie laptop. Now I don't need automounting. But I do need to be able to read and write ordinary unencrypted USB sticks withoug haveing to become root and guess a device names, and then still have trouble. Please make this easier. My friends see me struggling with this and thank God they are not using Linux. Poor PR, if nothing else. I get asked why I use Linux if it gives me such trouble. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
