On Tue, Jul 10, 2001 at 05:29:32AM -0800, Ethan Benson wrote:
nice to know pam_pwdfile gained md5 support, iirc it only did the
anchient crappy crypt before..
now there just needs to be a passwd command to work with this...
htpasswd
--
Nick Phillips -- [EMAIL PROTECTED]
Don't feed the
On Tue, Jul 17, 2001 at 12:29:45PM +0100, Nick Phillips wrote:
On Tue, Jul 10, 2001 at 05:29:32AM -0800, Ethan Benson wrote:
nice to know pam_pwdfile gained md5 support, iirc it only did the
anchient crappy crypt before..
now there just needs to be a passwd command to work with
On Tue, Jul 10, 2001 at 05:29:32AM -0800, Ethan Benson wrote:
nice to know pam_pwdfile gained md5 support, iirc it only did the
anchient crappy crypt before..
now there just needs to be a passwd command to work with this...
htpasswd
--
Nick Phillips -- [EMAIL PROTECTED]
Don't feed the
On Tue, Jul 17, 2001 at 12:29:45PM +0100, Nick Phillips wrote:
On Tue, Jul 10, 2001 at 05:29:32AM -0800, Ethan Benson wrote:
nice to know pam_pwdfile gained md5 support, iirc it only did the
anchient crappy crypt before..
now there just needs to be a passwd command to work with
On Tue, Jul 17, 2001 at 04:17:23AM -0800, Ethan Benson wrote:
On Tue, Jul 17, 2001 at 12:29:45PM +0100, Nick Phillips wrote:
On Tue, Jul 10, 2001 at 05:29:32AM -0800, Ethan Benson wrote:
nice to know pam_pwdfile gained md5 support, iirc it only did the
anchient crappy crypt before..
On Mon, Jul 09, 2001 at 08:38:56PM -0500, Martin Maney wrote:
Give me physical access and I don't need your root password, though it may
help make the job less detectable. But you don't get more security than you
physically have to begin with.
detectability is the key here, the case should
At 994738826s since epoch (07/10/01 02:20:26 -0400 UTC), Micah Anderson wrote:
These both seem like excellent practices, for the clueless in all of us -
can someone describe how this is done for sudo? How do you configure PAM to
require alternative passwords, which expire and age, and are
On Mon, 09 Jul 2001, Jason Healy wrote:
About the best you can hope for is to log to another machine (so
sudoers can't hose your logfiles), and be vigilant about checking what
they do.
Anyway, to your point about passwords, I say again (do we detect a
theme?): use PAM and make them use a
At 994740997s since epoch (07/10/01 03:56:37 -0400 UTC), Ethan Benson wrote:
detectability is the key here, the case should be locked shut ...
compare this to your envolope idea where the machine need not even be
shutdown and tell me which is more likely to go by unnoticed.
Okay, we've all
At 994738826s since epoch (07/10/01 02:20:26 -0400 UTC), Micah Anderson wrote:
These both seem like excellent practices, for the clueless in all of us -
can someone describe how this is done for sudo? How do you configure PAM to
require alternative passwords, which expire and age, and are
On Tue, Jul 10, 2001 at 09:05:18AM -0400, Jason Healy wrote:
apt-get install libpam-doc libpam-opie libpam-pwdfile
The first is docs, the second is OTP (one time passwords), and the
third is to authenticate against passwd-like files. The idea with
the third is that you make another passwd
On Tue, Jul 10, 2001 at 09:05:18AM -0400, Jason Healy wrote:
At 994738826s since epoch (07/10/01 02:20:26 -0400 UTC), Micah Anderson wrote:
These both seem like excellent practices, for the clueless in all of us -
can someone describe how this is done for sudo? How do you configure PAM to
At 994683614s since epoch (07/09/01 11:00:14 -0400 UTC), Micah Anderson wrote:
Having said that we do it this way as well, I'll point out one flaw which
particularly nags at me. Andreas said, a) allowing convenience by allowing
the user to effectively choose their own root passwd. which
, this is the same whether
or not you're using a shared root account, or sudo. If the admin is
ssh'ing in from home, on a compromised windows box, and using any type
of root function, the attacker now has the capability to do the same.
If you're worried about this sort of thing, again, policy is the
most
[EMAIL PROTECTED] writes:
alias /bin/su='/var/tmp/hax0rSu'
i would consider this a bug in the shell.
Note that \/bin/su would avoid the alias.
Note that
alias '\/bin/su'=echo eek
comments accordingly on one's ability to bypass *that*, too.
Woops. :)
~Tim
--
On Mon, Jul 09, 2001 at 08:23:43PM +0100, Tim Haynes wrote:
Note that
alias '\/bin/su'=echo eek
comments accordingly on one's ability to bypass *that*, too.
Woops. :)
Have you tried it? :-) At least with my version of bash (2.05.0(1)-release)
it won't do it. Or rather it'll
[EMAIL PROTECTED] writes:
On Mon, Jul 09, 2001 at 08:23:43PM +0100, Tim Haynes wrote:
Note that
alias '\/bin/su'=echo eek
comments accordingly on one's ability to bypass *that*, too.
Woops. :)
Have you tried it? :-) At least with my version of bash
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jason == Jason Healy [EMAIL PROTECTED] writes:
Jason Our solution to this (multiple admins on a single box) was to
Jason write the root password (some horribly cryptic thing) down on a
Jason piece of paper and put it in a sealed envelope, which we
from `man zsh`:
Alias expansion is done on the shell input before any
other expansion except history expansion. Therefore, if
an alias is defined for the word foo, alias expansion may
be avoided by quoting part of the word, e.g. \foo. But
there is
Nice little storm of a chain I managed to start here... Quite off
the original topic, mainly, where I trust the users. Many good points
have been noted and basically all of them have been argued both pro and
con. I will do a little summary here:
1) Some people like sudo, some think it is not
At 994696370s since epoch (07/09/01 04:32:50 -0400 UTC), Juha J?ykk? wrote:
One question raises however: If I have multiple uid=0 accounts,
will any of their passwords suffice as root password when entering
single user mode? Obviously sudo will not do here, so I will need a
root password,
I agree with this assessment of Andreas' - in fact this is what we use in
our organization. Unfortunately we don't have the luxury of fully trusting
admins, so I am a little paranoid about giving out full-on sudo to people,
but this is mostly a personnel issue having to do with the nature of the
At 994683614s since epoch (07/09/01 11:00:14 -0400 UTC), Micah Anderson wrote:
Having said that we do it this way as well, I'll point out one flaw which
particularly nags at me. Andreas said, a) allowing convenience by allowing
the user to effectively choose their own root passwd. which roughly
, this is the same whether
or not you're using a shared root account, or sudo. If the admin is
ssh'ing in from home, on a compromised windows box, and using any type
of root function, the attacker now has the capability to do the same.
If you're worried about this sort of thing, again, policy is the
most
On Sat, Jul 07, 2001 at 03:16:39AM -0800, Ethan Benson wrote:
On Sat, Jul 07, 2001 at 10:31:56AM +, Jim Breton wrote:
On Sat, Jul 07, 2001 at 01:56:56AM -0800, Ethan Benson wrote:
which may not work if you always type the
full path to /bin/su anyway.
Hoping he doesn't:
[EMAIL PROTECTED] writes:
alias /bin/su='/var/tmp/hax0rSu'
i would consider this a bug in the shell.
Note that \/bin/su would avoid the alias.
Note that
alias '\/bin/su'=echo eek
comments accordingly on one's ability to bypass *that*, too.
Woops. :)
~Tim
--
On Mon, Jul 09, 2001 at 08:23:43PM +0100, Tim Haynes wrote:
Note that
alias '\/bin/su'=echo eek
comments accordingly on one's ability to bypass *that*, too.
Woops. :)
Have you tried it? :-) At least with my version of bash (2.05.0(1)-release)
it won't do it. Or rather it'll take
[EMAIL PROTECTED] writes:
On Mon, Jul 09, 2001 at 08:23:43PM +0100, Tim Haynes wrote:
Note that
alias '\/bin/su'=echo eek
comments accordingly on one's ability to bypass *that*, too.
Woops. :)
Have you tried it? :-) At least with my version of bash
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jason == Jason Healy [EMAIL PROTECTED] writes:
Jason Our solution to this (multiple admins on a single box) was to
Jason write the root password (some horribly cryptic thing) down on a
Jason piece of paper and put it in a sealed envelope, which we
from `man zsh`:
Alias expansion is done on the shell input before any
other expansion except history expansion. Therefore, if
an alias is defined for the word foo, alias expansion may
be avoided by quoting part of the word, e.g. \foo. But
there is
On Mon, Jul 09, 2001 at 09:33:12AM -0400, Jason Healy wrote:
Our solution to this (multiple admins on a single box) was to write
the root password (some horribly cryptic thing) down on a piece of
paper and put it in a sealed envelope, which we then stuck to the
machine. The machine was
On Mon, Jul 09, 2001 at 04:18:10PM -0800, Ethan Benson wrote:
On Mon, Jul 09, 2001 at 09:33:12AM -0400, Jason Healy wrote:
machine. The machine was locked in the server room, so the only
people who could get to the root password (and the console) were the
people with keys. If you needed
This is completely off-topic at this point, but there are a few uses
of sudo. The original poster trusts his admins, and wants to give
them all root privs without the hassle of having them all use one
account. Sudo is not enforcing anything in this case, it is merely
a) allowing convenience by
Ethan == Ethan Benson [EMAIL PROTECTED] writes:
Ethan On Sat, Jul 07, 2001 at 02:10:09AM +0100, Eric E Moore wrote:
I would be very shocked if you could compromise a system with a
sudoers entry of: me hostname = (root) /bin/cat
Ethan i would not, being able to read every file on the system,
Eric E Moore [EMAIL PROTECTED] writes:
Ok, the amount of aiming away from your foot that you can do with
giving someone priveleges by giving them the root password is a proper
subset of the aiming away from your foot that you can do when
granting priveleges through sudo.
Think of a daemon
- Original Message -
From: Robert L. Yelvington [EMAIL PROTECTED]
To: debian-security@lists.debian.org
Sent: Friday, July 06, 2001 12:29 PM
Subject: Re: shared root account
what's to stop a person, once they've sudo'd, from editing
/etc/sudoers and
giving themselves more privs
This is completely off-topic at this point, but there are a few uses
of sudo. The original poster trusts his admins, and wants to give
them all root privs without the hassle of having them all use one
account. Sudo is not enforcing anything in this case, it is merely
a) allowing convenience by
On Fri, Jul 06, 2001 at 05:45:52PM -0700, Vineet Kumar wrote:
You make a good point, even if one of your examples is flawed:
$ sudo 'cat s /etc/sudoers'
sudo: cat s /etc/sudoers: command not found
er yeah that quoting is bogus, im pretty sure you can do that command
in sudo if you
On Sat, Jul 07, 2001 at 02:54:27AM +0200, Simon Huggins wrote:
Any user account that has access to the administrative account if
compromised can give the attacker the admin account etc.
sudo here is no worse than having your account compromised, your keys
sniffed and su really.
the
On Sat, Jul 07, 2001 at 02:10:09AM +0100, Eric E Moore wrote:
I would be very shocked if you could compromise a system with a
sudoers entry of:
me hostname = (root) /bin/cat
i would not, being able to read every file on the system, even if you
can't write is going to lead to compromise sooner
On Sat, Jul 07, 2001 at 01:56:56AM -0800, Ethan Benson wrote:
which may not work if you always type the
full path to /bin/su anyway.
Hoping he doesn't:
alias /bin/su='/var/tmp/hax0rSu'
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
On Sat, Jul 07, 2001 at 03:16:39AM -0800, Ethan Benson wrote:
alias /bin/su='/var/tmp/hax0rSu'
i would consider this a bug in the shell.
I disagree; from the Bash man page:
The alias name and the replacement text may con-
tain any valid shell input, including the
On Fri, Jul 06, 2001 at 12:15:43PM +0300, Juha J?ykk? wrote:
I have a bit of a situation: I have a handful of linux machines
(almost all with different distributions and kernels and software -
one hell to keep secure) and all the machines have different roots.
These guys want to keep their
On Fri, 06 Jul 2001, Juha J?ykk? [EMAIL PROTECTED] wrote...
: (Put the public key in the .authorized_keys file for the root user)
: TUrn on RSA/DSA authentication and 'allow root login'
: One word of warning aboce would allow logging in using root password as
well
:
: I distrust
On Sat, Jul 07, 2001 at 02:10:09AM +0100, Eric E Moore wrote:
[cut]
I would be very shocked if you could compromise a system with a
sudoers entry of:
me hostname = (root) /bin/cat
Depends on what's on the system. I've thought of four similar ways.
1:
With Kerberos, you can steal someone's
On Sat, Jul 07, 2001 at 12:11:44AM -0600, Will Aoki wrote:
On Sat, Jul 07, 2001 at 02:10:09AM +0100, Eric E Moore wrote:
[cut]
I would be very shocked if you could compromise a system with a
sudoers entry of:
me hostname = (root) /bin/cat
Depends on what's on the system. I've thought of
On Fri, Jul 06, 2001 at 05:45:52PM -0700, Vineet Kumar wrote:
You make a good point, even if one of your examples is flawed:
$ sudo 'cat s /etc/sudoers'
sudo: cat s /etc/sudoers: command not found
er yeah that quoting is bogus, im pretty sure you can do that command
in sudo if you properly
On Sat, Jul 07, 2001 at 02:54:27AM +0200, Simon Huggins wrote:
Any user account that has access to the administrative account if
compromised can give the attacker the admin account etc.
sudo here is no worse than having your account compromised, your keys
sniffed and su really.
the
On Sat, Jul 07, 2001 at 02:10:09AM +0100, Eric E Moore wrote:
I would be very shocked if you could compromise a system with a
sudoers entry of:
me hostname = (root) /bin/cat
i would not, being able to read every file on the system, even if you
can't write is going to lead to compromise sooner
On Fri, Jul 06, 2001 at 10:24:28PM -0500, Nathan E Norman wrote:
Depends on how you use it.
At my last job, we used sudo for two reasons:
1) I didn't have to inform all the admins whenever the root password
changed.
which is bogus since changing the root password means changing each
and
On Sat, Jul 07, 2001 at 01:56:56AM -0800, Ethan Benson wrote:
which may not work if you always type the
full path to /bin/su anyway.
Hoping he doesn't:
alias /bin/su='/var/tmp/hax0rSu'
On Sat, Jul 07, 2001 at 10:31:56AM +, Jim Breton wrote:
On Sat, Jul 07, 2001 at 01:56:56AM -0800, Ethan Benson wrote:
which may not work if you always type the
full path to /bin/su anyway.
Hoping he doesn't:
alias /bin/su='/var/tmp/hax0rSu'
i would consider this a bug in the
[]
yup, which is why nobody gets root but me. if i ever for some reason
decided to go back to sysadmin work a criteria for employment would be
that no manager, sales guy, or other morons would be permitted access
to root for ANY REASON, period, end of story.
as for sudo for my own
On Sat, Jul 07, 2001 at 03:16:39AM -0800, Ethan Benson wrote:
alias /bin/su='/var/tmp/hax0rSu'
i would consider this a bug in the shell.
I disagree; from the Bash man page:
The alias name and the replacement text may con-
tain any valid shell input, including the
On Fri, Jul 06, 2001 at 12:15:43PM +0300, Juha J?ykk? wrote:
I have a bit of a situation: I have a handful of linux machines
(almost all with different distributions and kernels and software -
one hell to keep secure) and all the machines have different roots.
These guys want to keep their
On Fri, Jul 06, 2001 at 12:15:43PM +0300, Juha Jäykkä wrote:
Make multiple root-accounts. We for example have normal users
accounts and 3-5 root-accounts depending on machine. Just give
UID/GID to new user.
I have a bit of a situation: I have a handful of linux machines
(almost all with
On Fri, Jul 06, 2001 at 12:25:20PM +0300, Saku Ytti wrote:
On Fri, Jul 06, 2001 at 12:15:43PM +0300, Juha Jäykkä wrote:
Make multiple root-accounts. We for example have normal users
accounts and 3-5 root-accounts depending on machine. Just give
UID/GID to new user.
Insert 0 where
On Fri, Jul 06, 2001 at 12:15:43PM +0300, Juha J?ykk? wrote:
I have a bit of a situation: I have a handful of linux machines
(almost all with different distributions and kernels and software -
..
time (we all know keeping up security is a fulltime job). Obviously to
install patches etc I,
On Fri, Jul 06, 2001 at 11:35:16AM +0200, Mark Janssen wrote:
(Put the public key in the .authorized_keys file for the root user)
TUrn on RSA/DSA authentication and 'allow root login'
One word of warning aboce would allow logging in using root password as well
which might not be the best
On Fri, Jul 06, 2001 at 01:19:24PM +0300, Juha Jykk wrote:
I distrust allowing root logins from anywhere but local console(s)
or non-modem gettys i.e. from anywhere over the not-owned-by-me cable.
umm do You want to run in circles from one machine to another? ;o))
if not than You need to
Am Freitag, 6. Juli 2001 12:19 schrieb Juha Jäykkä:
(Put the public key in the .authorized_keys file for the root user)
TUrn on RSA/DSA authentication and 'allow root login'
One word of warning aboce would allow logging in using root password as
well
I distrust allowing root
Just a friendly Jedi Knight wrote:
On Fri, Jul 06, 2001 at 01:19:24PM +0300, Juha Jykk wrote:
I distrust allowing root logins from anywhere but local console(s)
or non-modem gettys i.e. from anywhere over the not-owned-by-me cable.
umm do You want to run in circles from one machine to
At 994443564s since epoch (07/06/01 06:19:24 -0400 UTC), Juha J?ykk? wrote:
I distrust allowing root logins from anywhere but local console(s)
or non-modem gettys i.e. from anywhere over the not-owned-by-me cable.
Any other ideas? Or is it really safe to allow root logins to sshd?
It is
On 06-Jul-01, 05:34 (CDT), Patrice Neff [EMAIL PROTECTED] wrote:
What you want to accomplish might be possible with sudo. Install sudo
and thenn add the following line to the configuration
file. (/etc/sudoers on my machine)
yourusername ALL=(ALL) ALL
this will allow you to execute
Juha Jäykkä [EMAIL PROTECTED] writes:
Any other ideas? Or is it really safe to allow root logins to sshd?
It is just an old rule of thumb that root must never log on over the
wire but that may be old news from times of telnet - never had any
need of root logins over the wire until perhaps
On Fri, Jul 06, 2001 at 03:24:56PM -0800, Ethan Benson wrote:
On Fri, Jul 06, 2001 at 09:43:55AM -0500, Nathan E Norman wrote:
OTOH if you restrict the user to a list of commands in /etc/sudoers,
it's wise to consider whether the user might be able to leverage one of
those commands to
On Sat, Jul 07, 2001 at 02:10:09AM +0100, Eric E Moore wrote:
[cut]
I would be very shocked if you could compromise a system with a
sudoers entry of:
me hostname = (root) /bin/cat
Depends on what's on the system. I've thought of four similar ways.
1:
With Kerberos, you can steal someone's
I have a bit of a situation: I have a handful of linux machines
(almost all with different distributions and kernels and software -
one hell to keep secure) and all the machines have different roots.
These guys want to keep their root passwords (or at least the root
privileges) so they can
On Fri, Jul 06, 2001 at 12:15:43PM +0300, Juha Jäykkä wrote:
Make multiple root-accounts. We for example have normal users
accounts and 3-5 root-accounts depending on machine. Just give
UID/GID to new user.
I have a bit of a situation: I have a handful of linux machines
(almost all with
On Fri, Jul 06, 2001 at 12:25:20PM +0300, Saku Ytti wrote:
On Fri, Jul 06, 2001 at 12:15:43PM +0300, Juha Jäykkä wrote:
Make multiple root-accounts. We for example have normal users
accounts and 3-5 root-accounts depending on machine. Just give
UID/GID to new user.
Insert 0 where
On Fri, Jul 06, 2001 at 12:15:43PM +0300, Juha J?ykk? wrote:
I have a bit of a situation: I have a handful of linux machines
(almost all with different distributions and kernels and software -
..
time (we all know keeping up security is a fulltime job). Obviously to
install patches etc I,
On Fri, Jul 06, 2001 at 12:15:43PM +0300, Juha Jäykkä wrote:
I have a bit of a situation: I have a handful of linux machines
(almost all with different distributions and kernels and software -
one hell to keep secure) and all the machines have different roots.
These guys want to keep
On Fri, Jul 06, 2001 at 11:35:16AM +0200, Mark Janssen wrote:
(Put the public key in the .authorized_keys file for the root user)
TUrn on RSA/DSA authentication and 'allow root login'
One word of warning aboce would allow logging in using root password as well
which might not be the best
(Put the public key in the .authorized_keys file for the root user)
TUrn on RSA/DSA authentication and 'allow root login'
One word of warning aboce would allow logging in using root password as well
I distrust allowing root logins from anywhere but local console(s)
or non-modem gettys
On Fri, Jul 06, 2001 at 01:19:24PM +0300, Juha Jäykkä wrote:
I distrust allowing root logins from anywhere but local console(s)
or non-modem gettys i.e. from anywhere over the not-owned-by-me cable.
umm do You want to run in circles from one machine to another? ;o))
if not than You need to
Am Freitag, 6. Juli 2001 12:19 schrieb Juha Jäykkä:
(Put the public key in the .authorized_keys file for the root user)
TUrn on RSA/DSA authentication and 'allow root login'
One word of warning aboce would allow logging in using root password as
well
I distrust allowing root
Juha Jäykkä [EMAIL PROTECTED] writes:
How can that _safely_ be accomplished? There are versions of su,
sudo etc) that do not ask passwords, there are suid binaries but
which is _THE_ way of accomplishing this?
I've never been in a situation like yours. But I can tell how I do it
at home. I
At 994443564s since epoch (07/06/01 06:19:24 -0400 UTC), Juha J?ykk? wrote:
I distrust allowing root logins from anywhere but local console(s)
or non-modem gettys i.e. from anywhere over the not-owned-by-me cable.
Any other ideas? Or is it really safe to allow root logins to sshd?
It is
On Fri, Jul 06, 2001 at 09:18:18AM -0400, Jason Healy wrote:
types of
passwords accepted to run root commands, etc).
elaborate.
the main reason i don't use sudo except for small things which cannot
grant a root shell in any way is for the simple reason the sudo
converts a normal unprivleged
admittedly, i am not very familiar with sudo because i have never seen the
practical advantages of making su'ing more of a hassle by having to manage
another set of conf files and keeping track of who's a sudoer and,
therefore, have chosen not to use it.
what's to stop a person, once they've
On Fri, Jul 06, 2001 at 09:29:54AM -0700, Robert L. Yelvington wrote:
admittedly, i am not very familiar with sudo because i have never seen the
practical advantages of making su'ing more of a hassle by having to manage
another set of conf files and keeping track of who's a sudoer and,
Juha Jäykkä [EMAIL PROTECTED] writes:
Any other ideas? Or is it really safe to allow root logins to sshd?
It is just an old rule of thumb that root must never log on over the
wire but that may be old news from times of telnet - never had any
need of root logins over the wire until perhaps
At 994418143s since epoch (07/06/01 10:15:43 -0400 UTC), Ethan Benson wrote:
On Fri, Jul 06, 2001 at 09:18:18AM -0400, Jason Healy wrote:
types of
passwords accepted to run root commands, etc).
elaborate.
the main reason i don't use sudo except for small things which cannot
grant a
On Fri, Jul 06, 2001 at 09:43:55AM -0500, Nathan E Norman wrote:
OTOH if you restrict the user to a list of commands in /etc/sudoers,
it's wise to consider whether the user might be able to leverage one of
those commands to edit /etc/sudoers (or any other file). If you're
going to list
You make a good point, even if one of your examples is flawed:
$ sudo 'cat s /etc/sudoers'
sudo: cat s /etc/sudoers: command not found
sudo is a very useful tool in the type of situation described in this
thread. Even if you give everyone ALL=(ALL) ALL, it's better than su
or even
On Fri, Jul 06, 2001 at 06:15:43AM -0800, Ethan Benson wrote:
the main reason i don't use sudo except for small things which cannot
grant a root shell in any way is for the simple reason the sudo
converts a normal unprivleged user password into another root
password.
Any user account that
Ethan == Ethan Benson [EMAIL PROTECTED] writes:
Ethan or even seemingly innocuous things like less or even cat.
Less is a problem, yes, as is anything else with a shell escape.
Ethan sudo less anything !/bin/sh whoami r00t!
Ethan echo me ALL=ALL s sudo 'cat s /etc/sudoers'
doesn't work.
On Fri, Jul 06, 2001 at 03:24:56PM -0800, Ethan Benson wrote:
On Fri, Jul 06, 2001 at 09:43:55AM -0500, Nathan E Norman wrote:
OTOH if you restrict the user to a list of commands in /etc/sudoers,
it's wise to consider whether the user might be able to leverage one of
those commands to
88 matches
Mail list logo
