On Tuesday February 10 2015 19:30:59 Ryan Schmidt wrote:
Hi Ryan,
>I've also made additional changes to make it impossible for me to forget to
>use sudo:
Could it be those are indeed quite necessary (i.e. you forgot to list the
changes)? ;)
>You're talking about two different things.
You know, I think that by now I have a pretty good idea about what's possible
and what you guys consider the best approach.
I agree that a shell wrapper alias is better than editing sudoers in that's
(probably) more difficult for malware to exploit.
I also know that I have my own, possibly idiosyncratic view on security that
stems from personal experience which doesn't include managing systems used by
multiple users or having a server role.
I largely prefer to use traditional permissions to give me (as an admin user)
access to certain non-critical areas of the filesystem than to become lazy by
rendering the sudo implicit for (in the end) more and more commands. I think
the only commands for which I've done that by now are zfs and zpool because (on
Linux) it's not (yet) possible to use something like a user= flag in /etc/fstab
with ZFS. When I have to do a significant bunch of things that all require root
permissions I prefer to do a `sudo tcsh -l` and put up a big freaking prompt
that clearly shows I have to watch every step I make.
There's another reason why just doing 'sudo port' isn't really an option. I
don't know how other port developers work, but given the amount of editing,
patching and other typical dev stuff I'm doing in between `port
{configure,build,destroot}` the only way I see to follow official protocol and
NOT use sudo all the time is to set up that dedicated macports user account as
a full account, and login to that. On *nix/X11 it would be possible to host a
separate user session inside your main login session but not on a single OS X
machine without using a VM.
Hence my choice for how I do things. I appreciate the warning about badly
behaved ports; evidently I knew (somewhere) that this would be possible, I had
never really considered it though. Fortunately the ports I use have all been
vetted correctly before being admitted.
It would be different if there were a development version of port, or else
tools like `mp-configure` `mp-build` etc. that port developers can use setting
up a port, adapting the code, etc. I've tried to roll my own wrapper script to
be able to execute cmake or configure or make with the environment that port
imposes, so that I can at least do those steps (or repeat them, for
configure/cmake) without having to go through port. That allows me to build
inside an IDE and be reasonably sure that the result is not completely
different from what `port build` would give (nb: a `make` step can cause
configure or cmake to be invoked).
I hope this doesn't come across as yet another confused mail - it's one of
those days I'm not home alone and keep getting distracted with/by/for household
chores.
R
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
