sudo or doas

How do you run as root, sudo or doas?

  • sudo

    Votes: 26 35.6%

  • doas

    Votes: 32 43.8%

  • something else (what)

    Votes: 6 8.2%

  • login as root and don't care

    Votes: 9 12.3%
  • Total voters
    73
eternal_noob said:
What's wrong with temporarily becoming root via su -, do the work and CTRL +d back to the user?
Click to expand...
Problematic if you have to delegate certain tasks to other people. Then you have to give them the root password, which you don't want to do in a larger organization. We have application maintainers, they can stop/start and reconfigure the application service they maintain. You don't want to have to give them the root password.
 
I can't see which tasks that would be.

Edit files? Edit them in your f*cking $HOME, root copies them later.
Install software? Forget it, only root does it.
View logfiles? Add a dedicated group and change permissions

Edit: Ok, the reason you edited in makes sense (until i can think of a better solution).
 
eternal_noob said:
I can't see which tasks that would be.

Edit files? Edit them in your f*cking $HOME, root copies them later.
Install software? Forget it, only root does it.
View logfiles? Add a dedicated group and change permissions
Click to expand...
Try maintaining 900+ servers running a myriad of different software. We maintain the platform, other specialized teams maintain the software.
 
I recently switched to doas because sudo has become bloaty and is starting to have security problems. The lack of persist on Freebsd is really kind of a killer, though and I'll probably switch back.

Why not su -? Because I don't like interactive sessions as root. I don't want to get used to it. Having to type "sudo" or "doas" is just enough friction to make me think about what I'm going to do for a fraction of a second longer. Sometimes that makes all the difference.

I do wish it was easier (or even possible!) to build ports as an unprivileged user. I work around this by building everything in a jail, but that adds a little too much friction. I like the peace of mind of knowing that my user account simply can't write to most places in my filesystems. That's one of the killer features of Unix-like operating systems.
 
eternal_noob said:
Edit: Ok, the reason you edited in makes sense (until i can think of a better solution).
Click to expand...
There are certainly better solutions to think of. I've suggested a couple already, but those application maintainers typically don't want to change the way they've been working for the past decade or so. So it's very difficult to actually get some of that implemented. Will need to take baby steps and a lot of negotiation in order to change anything.
 
I use su via ssh or a desktop terminal logged in as a lower level user, so I checked the 3rd option.

Partly out of old crusty habits, and partly because I've never worked out of any shop which had over 10 programmers.
 
I want to use doas, but I think with the lack of persist makes it too impractical.

I'm used to sudo from working with Linux, and use that extensively in my job. I suppose I'm in that application maintainer category that was mentioned above. Our sysadmins also use sudo themselves.
 
shkhln said:
Weird. That works just fine already and, in fact, is explicitly supported: https://github.com/freebsd/freebsd-...0c0f93a6313f874decc1c9e99/CHANGES#L1709-L1720.
Click to expand...
Didn't work the last time I tried, and spent a lot of time chasing my own tail setting environment variables that had little or no effect. There isn't a single place where the process and all the variables involved are documented. That changelog implies there are ports that can't be built without root ("NEED_ROOT"). It looks like the only way to find out is to grep all the makefiles.

It's possible it works now, but I'm not going to be the first one to figure it out.
 
I use su. I see there are usecases for these tools (selectively allowing who can execute what as super-user), but as the only operator in my private network, I don't need that. And on the plus side, if my password is ever compromised, there's still the root password ;)
 
I have a few sudo rules where the command is something like "/sbin/pfctl -t blocks -T *" where the * acts as a wildcard for any further arguments after the command. doas can't do that so it's useless for me. Shame really as I also dislike sudo.

What I mostly do though is have one window in my tmux session called root which has a permanent "su -" in it.
 
Mr. Salty said:
We're around 30,000 Linux servers and 1,000 Linux workstations, but that does not include thousands of containers spun up for Java, or Windows which I'd approximate to be about 2,000 servers (not Windows workstations which would be several thousand).
Click to expand...
And I presume you're not giving out the root password for all those server to various other teams or groups of people either. I'm quite sure you have something in place for that.

When you're a small team managing a handful of servers it might be fine to share the root password when needed, and just stick to su(1). When teams and environments get larger you need to start delegating tasks to other teams. I've been to places that were very much in a transitional phase from small to medium sized and it's just simple to use sudo(8) to root and let them handle it. The place I'm currently employed is more in a medium to large transition. We don't allow blank sudo(8), if you require access to certain services you only get to touch those services and nothing more. We have a large selection of rules, and puppet makes sure the correct rules for that server (and application) are applied. Even getting on to the servers is also very restricted. There are still plenty of improvements to make, and a recent piss poor performance on a pentest showed them they were doing it wrong for too long (most of that misery pertains to windows systems, more correctly, the people that maintained those windows servers). So they're now trying to shore up their security (and procedures). I'm going to take that as an opportunity to introduce more drastic improvements. Strike while the iron is hot.
 
SirDice said:
Try maintaining 900+ servers running a myriad of different software. We maintain the platform, other specialized teams maintain the software.
Click to expand...

Indeed. Depending on your circumstances, there may be a multitude of teams with a stake in the management of your systems. These might include:
  • the Unix Support team (who do the Unix work);
  • the Operating System Monitoring team (who look for Unix-related problems, 24x7);
  • the Gateway team (who manage the nexus to the Internet);
  • the Developer team (who write the applications);
  • the Application Support team (who investigate application problems);
  • the Application Monitoring team (who look for application problems, 24x7);
  • the Transaction Monitoring team (end-to-end instrumentation of all transactions);
  • the Database team (which is just another kind of application);
  • the Internal Security team (who watch everyone, including the other watchers);
  • the Log Management team (central collection, and analysis of logs);
  • the SAN management team (who look after all the storage);
  • the Network team (who direct the electrons);
  • the Project Management team (who organise and direct multi-disciplinary activities); and
  • the Quality Assurance team who co-ordinate all the other teams.
I have worked in places where most of these teams were present, and separately constituted.

Changes to production systems are going to be rigidly controlled. But there still has to be mechanisms for application support people to perform their routine work requiring elevated privilege (e.g. application start, stop, and software release).

The development, test, and hot-fix environments would all require privilege escalations to get a wide range of routine work done by developer, application support, and test teams.

In a security-minded environment, you have to trust the Unix administrators to some extent ( su still gets logged), but for everyone else, all routine privilege escalations would be controlled by sudo (or similar), logged, and analysed automatically for any sign of problems. In these situations the log management team is generally held at length (and often physically separated in a secure situation). All non-routine changes would be raised, approved, and passed, via some formal work management system, to the team(s) with the required authorisations.

And, su - by anyone outside Unix support is is most certainly a clear sign of malfeasance... It would attract a lot of attention...
 
Mr. Salty said:
We're around 30,000 Linux servers and 1,000 Linux workstations, but that does not include thousands of containers spun up for Java, or Windows which I'd approximate to be about 2,000 servers (not Windows workstations which would be several thousand).
Click to expand...
Yes, yes. I've got a billion servers.

But what do you use, sudo or doas?
 
both.gif


On some systems I installed both because when sudo(8) was killed because or 'wrong' </usr/local>/etc/sudoers then you could use doas(1) to fix it :)
 
Last edited:
You must log in or register to reply here.
Back
Top