2012/10/9 Todd C. Miller todd.mil...@courtesan.com:
This is normal behavior for the version of sudo that ships with
OpenBSD. You can enable per-tty timestamps by enabling the tty_tickets
option. E.g., in sudoers add a line like:
Defaults tty_tickets
- todd
Confusingly sudoers(5) says
On 04/20/10 00:37, Frank Bax wrote:
The first example in 'man sudo' shows how to list files in a protected
directory:
sudo ls /usr/local/protected
I am not sure how I would search the contents of files found in such a
directory, for example:
$ sudo ls -l /var/spool/mqueue
The first example in 'man sudo' shows how to list files in a protected
directory:
sudo ls /usr/local/protected
I am not sure how I would search the contents of files found in such a
directory, for example:
$ sudo ls -l /var/spool/mqueue/
total 8
-rw--- 1
Use grep -r?
On Mon, Apr 19, 2010 at 06:37:23PM -0400, Frank Bax wrote:
The first example in 'man sudo' shows how to list files in a
protected directory:
sudo ls /usr/local/protected
I am not sure how I would search the contents of files found in such
a directory, for example
Subject says it all, really. There are probably more people out there
who feel that given a little more time than we actually have on our
hands right now, it would be really great to sit down and crate the
sudo config of our dreams. Better yet, If there was a compendium of
good configs with some
On Friday 24 April 2009 16.58.06 you wrote:
login_fingerprint only supports login auth, not support challenge/response
mode which is what sudo (and other things) uses.
Alright thanks! I've figured it is still useful because of the -a option of
sudo, and thanks to this I've discovered
Szia!
have you done this on -current or 4.5?
thanks,
Pau
2009/4/28 LEVAI Daniel l...@ecentrum.hu:
On Friday 24 April 2009 16.58.06 you wrote:
login_fingerprint only supports login auth, not support challenge/response
mode which is what sudo (and other things) uses.
Alright thanks! I've
is what sudo (and other things) uses.
Alright thanks! I've figured it is still useful because of the -a option
of sudo, and thanks to this I've discovered the username[:auth_type]
option when logging in on the console.
--
LIVAI Daniel
PGP key ID = 0x4AC0A4B1
Key fingerprint = D037 03B9 C12D
or login incorrect.
I see the same result as you with sudo. Annoying. Sudo must not be
feeding it correctly right, but perhaps login_fingerprint is expecting
wrongly.
It would be a neat gimmick if we could get this working!
-Nick
On 23/04/2009, LEVAI Daniel l...@ecentrum.hu wrote:
Hi!
I've set up
swipes but
whenever I do it says invalid swipe or login incorrect.
You need to enroll_fingerprint(8) as the target (root) user too, so root will
have a ~/.fprint directory too.
I see the same result as you with sudo. Annoying. Sudo must not be
feeding it correctly right, but perhaps login_fingerprint
.
I see the same result as you with sudo. Annoying. Sudo must not be
feeding it correctly right, but perhaps login_fingerprint is expecting
wrongly.
It would be a neat gimmick if we could get this working!
I just followed /usr/local/share/doc/login_fingerprint/README:
$ enroll_fingerprint -f 7
.
When I say su I actually meant I'm running su $USER.
Then you must run enroll_fingerprint as $USER, to make the
$USER_HOMEDIR/.fprint/ directory and the corresponding files.
I see the same result as you with sudo. Annoying. Sudo must not be
feeding it correctly right, but perhaps
) finger.
#
fingerprint:
:auth=-fingerprint,passwd:\
:x-fingerprint=7:\
:tc=default:
I've done the same thing except I've added this to the default class, so I
don't have to change the already made classes (which are
including auth-defaults).
and I had to do sudo
login_fingerprint only supports login auth, not support challenge/response
mode which is what sudo (and other things) uses.
- todd
On Fri, Apr 24, 2009 at 03:28:34AM -0400, Nick Guenther wrote:
omg we have finger print reader support??? !
yes, and it's really cool, since i've some quite sharp knifes.
(scnr)
Hi!
I've set up this login_fingerprint port and it is working fine in console
logins and with `su`, but with sudo I can't seem to get it to work.
I've modified my /etc/login.conf like this:
# Default allowed authentication styles
auth-defaults:auth=-fingerprint,passwd,skey:\
:x
Am 08.02.2009 um 16:18 schrieb Todd C. Miller:
Do you know whether tentakel is running ssh with the -t flag or
not?
I think tentakel's running without this flag. In the file /etc/
tentakel.conf I can see:
# first section: global parameters
set ssh_path=/usr/bin/ssh
Adding a -t at the end
All:
Do we want to slip this into presently supported branches containing
1.6.9p17? It's a quick patch:
http://www.sudo.ws/cgi-bin/cvsweb/sudo/parse.c.diff?r1=1.160.2.21r2=1.160.2.22only_with_tag=SUDO_1_6_9
I tested it on -rOPENBSD_4_3. Just be sure to nuke the version string.
$ more
In message 1234278635.17569.9.ca...@soundwave.ws.pitbpa0.priv.collaborativefus
ion.com
so spake Brian A. Seklecki (lavalamp):
Do we want to slip this into presently supported branches containing
1.6.9p17? It's a quick patch:
http://www.sudo.ws/cgi-bin/cvsweb/sudo/parse.c.diff?r1
Hi there,
is there any way to execute sudo (in combination with a password to
provide) on remote servers using tentakel? Actualy tentakel hangs,
when I'm executing sudo ls -l / on a bunch of servers. Without sudo
anything works fine, as you can see from the example below.
[f
In message c4bb3a29-8051-4d34-a691-53d4f035d...@smartterra.eu
so spake Falk Brockerhoff - smartTERRA GmbH (nmc):
is there any way to execute sudo (in combination with a password to
provide) on remote servers using tentakel? Actualy tentakel hangs,
when I'm executing sudo ls -l
Am Thu, 22 Jan 2009 14:04:00 +1100
schrieb Gavin Norman gav...@rcservices.com.au:
Greetings,
Anyone had any luck getting sudo working with YPLDAP/LDAP?
Regards.
You don't need ypldap. This is a LDAP-to-NIS server which provides NIS
maps for users and groups so You can fetch passwd/groups
I'm aware of that, but sudo whinges about uid x not being in /etc/passwd
if they are from ypldap.
Regards.
--
Gavin Norman
IT Manager
RC Services Vic
M: +614 0935 4020
E: gav...@rcservices.com.au
Greetings,
Anyone had any luck getting sudo working with YPLDAP/LDAP?
Regards.
--
Gavin Norman
IT Manager
RC Services Vic
E: gav...@rcservices.com.au
Hi list,
According to the manual for sudo, the -v command line switch does the following:
If given the -v (validate) option, sudo will update the user's
timestamp, prompting for the user's password if necessary. This
extends the sudo timeout for another 5 minutes (or whatever the
timeout is set
Sounds like you have a line like this in sudoers:
# Same thing without a password
%wheelALL=(ALL) NOPASSWD: SETENV: ALL
which would explain why you don't get prompted for a password.
But since you didn't include the output of sudo -l I
can't tell for sure.
- todd
2008/12/8 Todd C. Miller [EMAIL PROTECTED]:
Sounds like you have a line like this in sudoers:
# Same thing without a password
%wheelALL=(ALL) NOPASSWD: SETENV: ALL
which would explain why you don't get prompted for a password.
But since you didn't include the output of sudo -l I
Andreas Kahari wrote:
Hi list,
According to the manual for sudo, the -v command line switch does the following:
If given the -v (validate) option, sudo will update the user's
timestamp, prompting for the user's password if necessary. This
extends the sudo timeout for another 5 minutes
In message [EMAIL PROTECTED]
so spake Andreas Kahari (andreas.kahari):
Here you go:
$ sudo -l
Matching Defaults entries for ak on this host:
env_keep+=DESTDIR FETCH_CMD FLAVOR FTPMODE GROUP MAKE MULTI_PACKAGES,
env_keep+=OKAY_FILES OWNER PKG_DBDIR PKG_DESTDIR PKG_CACHE
Hi Andreas,
Andreas Kahari wrote on Mon, Dec 08, 2008 at 01:54:04PM +:
According to the manual for sudo, the -v command line switch does
the following:
If given the -v (validate) option, sudo will update the user's
timestamp, prompting for the user's password if necessary
2008/12/8 Alexander Hall [EMAIL PROTECTED]:
Andreas Kahari wrote:
Hi list,
According to the manual for sudo, the -v command line switch does the
following:
If given the -v (validate) option, sudo will update the user's
timestamp, prompting for the user's password if necessary
'
group execute the xfsm-shutdown-helper program, but this line has the
side effect of making sudo -v not work properly.
The following patch should fix the behavior. I need to do some
checking to make sure there are no other side effects but I believe
it is correct.
- todd
Index: parse.c
2008/12/8 Todd C. Miller [EMAIL PROTECTED]:
In message [EMAIL PROTECTED]
so spake Andreas Kahari (andreas.kahari):
Here you go:
$ sudo -l
Matching Defaults entries for ak on this host:
env_keep+=DESTDIR FETCH_CMD FLAVOR FTPMODE GROUP MAKE MULTI_PACKAGES,
env_keep
was intending to let any member of the 'users'
group execute the xfsm-shutdown-helper program, but this line has the
side effect of making sudo -v not work properly.
The following patch should fix the behavior. I need to do some
checking to make sure there are no other side effects but I believe
When I use ssh to run sudo on a remote host, the password for sudo gets
echoed to the screen. e.g.
# ssh -l kodos 10.101.101.01 sudo ls /
[EMAIL PROTECTED]'s password:
Password:0hNoesICit
Both local and remote hosts are using
OpenBSD 4.2 GENERIC#2 i386
OpenSSH_4.7
2008-03-22, Lars Noodin [EMAIL PROTECTED] wrote:
When I use ssh to run sudo on a remote host, the password for sudo gets
echoed to the screen. e.g.
# ssh -l kodos 10.101.101.01 sudo ls /
[EMAIL PROTECTED]'s password:
Password:0hNoesICit
For such things use `ssh -t
2008/3/23, Alexey Vatchenko [EMAIL PROTECTED]:
2008-03-22, Lars Noodin [EMAIL PROTECTED] wrote:
When I use ssh to run sudo on a remote host, the password for sudo gets
echoed to the screen. e.g.
# ssh -l kodos 10.101.101.01 sudo ls /
[EMAIL PROTECTED]'s password
performance testing I'm doing, I'm copying ipsec.conf files between
the systems and applying them using ipsecctl -f which of course
requires root privileges. I'm scripting this with perl since I'm
testing 24 different IPSec policies at a time.
What I've noticed is that when sudo (on the remote
.
What I've noticed is that when sudo (on the remote machine)
periodically asks me to reauthenticate myself prior to executing a
sudo command, the password prompt for the remote machine does not turn
off echo. This also happens if I ssh into my other machine with any
command that requires me
On 2007/11/17 16:54, Walter Goulet wrote:
What I've noticed is that when sudo (on the remote machine)
periodically asks me to reauthenticate myself prior to executing a
sudo command, the password prompt for the remote machine does not turn
off echo.
Any ideas as to why this happens
of the target file, and the result is copied to the target
with the right permissions afterwords. Executing shells from e.g vim
is no longer a security hole.
It is all in the man pages sudo(8) and sudoers(5).
snip
--
/ Raimo Niskanen, Erlang/OTP, Ericsson AB
On Sun, 16 Sep 2007, Matthew Szudzik wrote:
Does anyone currently use the operator group for anything, or is it just a
I do, for backups.
--
Antoine
Matthew Szudzik wrote:
The fact that you need to provide normal users with these kind of
privileges indicates a possible flaw in your overall scheme. You may
find that, after careful reconsideration, there are precious few
commands that you would actually have to allow the users to run with
On 9/17/07, Darrin Chandler [EMAIL PROTECTED] wrote:
problem is. This is why people keep asking you to explain the problem
more.
Sorry for being vague. Ok, I have these in /etc/sudoers for joeuser.
joeuser is also in the wheel group.
joeuser server = NOPASSWD: /sbin/mount,
* Matthew Szudzik [EMAIL PROTECTED] [2007-09-17 04:41]:
Does anyone currently use the operator group for anything
sure, taking dump(8)s
--
Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED]
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated
On Sun, Sep 16, 2007 at 10:33:59PM -0400, Matthew Szudzik wrote:
| /sbin/halt
SNIP
| Does anyone currently use the operator group for anything, or is it just a
| historical vestige? Would there be anything wrong with giving the
| operator enough hardware access to run the commands above?
If
If you're in operator, you can at least shutdown or reboot your system
with /sbin/shutdown (which is setuid root and executable by those in
operator).
But (as I mentioned in the message), shutdown makes a very annoying beep.
When shutting down the laptop in a hushed boardroom or lecture
On 2007/09/17 09:52, Matthew Szudzik wrote:
But (as I mentioned in the message), shutdown makes a very annoying beep.
You might find this useful:
$ grep bell /usr/src/etc/wsconsctl.conf
#keyboard.bell.volume=0 # mute keyboard beep
/bin/vim /etc/pf.conf
Same comments as about previous vi-as-root. Make these files
rw by group wheel, and no sudo is needed. Changes might be needed
to /etc, too. Consider making /etc/motd a symbolic link to a
file that joe can edit without privilege. This might work with
pf.conf, too, but I dunno
On Mon, Sep 17, 2007 at 09:52:06AM -0400, Matthew Szudzik wrote:
If you're in operator, you can at least shutdown or reboot your system
with /sbin/shutdown (which is setuid root and executable by those in
operator).
But (as I mentioned in the message), shutdown makes a very annoying beep.
On 9/17/07, Chris [EMAIL PROTECTED] wrote:
Ok, I have these in /etc/sudoers for joeuser.
joeuser is also in the wheel group.
Why are you adding wheel group membership? Root access through
sudo(8) does not require the user to be a member of wheel, but su(8)
does.
Jim
On Sun, 16 Sep 2007, Matthew Szudzik wrote:
What's a laptop user to do?
Run as root -- why not?
Be careful. Limit PATH. Keep the cat off the keyboard. (This
can be pesky if you're using vi at the time.)
Open a root xterm, make the background some weird color, use a font
and size you don't
for conditions and sysctl settings.
If you still want to go the sudo route after the comments you have
received, that is your decision. You can create server, user and
command groups in sudoers to help keep your sudoers file sane. See man
page for exact syntax.
-Keith
On 9/16/07, Aaron W. Hsu [EMAIL PROTECTED] wrote:
What exactly are you trying to enable users to do? The fact that you need to
provide normal users with these kind of privileges indicates a possible flaw
in your overall scheme. You may find that, after careful reconsideration,
there are
Chris wrote:
On 9/16/07, Aaron W. Hsu [EMAIL PROTECTED] wrote:
What exactly are you trying to enable users to do? The fact that you need to
provide normal users with these kind of privileges indicates a possible flaw
in your overall scheme. You may find that, after careful reconsideration,
Chris wrote:
...
user server = NOPASSWD: /sbin/mount, /usr/libexec/locate.updatedb
I might suggest using groups rather than individual users in sudoers.
On the small scale both are about the same, but using groups scales
better (both time and quantity).
So the above could be for the group
be a better way to do what you're trying to do,
but we won't know that until we understand what it is you're trying to
do. (In the big picture sense, not in the how do I make this work
with sudo? sense.)
As far as adding users to the sudoers file, doing so usually implies a
certain level of trust
the problem
more. Possible answers might be: write a special suid script and only
give sudo access to that; give sudoers specs for each and every command
needed; give full sudo access and imprison the user if they abuse it.
There are so many more options it's not even funny, and nobody can tell
which
Chris,
Thanks for the message...
Chris So what's the ideal way to do things?
Of course, the ``ideal'' way to do anything really depends on what you want to
do. It would help if you could give us some more details about what you are
trying to do on the grand scheme of things, so that we could
chmod u+s /usr/local/bin/xsh
then only tell the trusted users about xsh, and you can avoid sudo altogether.
Ted Unangst wrote:
cp /bin/sh /usr/local/bin/xsh
chmod u+s /usr/local/bin/xsh
then only tell the trusted users about xsh,
and you can avoid sudo altogether.
Ohhh... EEEVVVILLL... :)
--
[100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salax
I been looking for ways to let normal user run privileged commands and
after some searching found that adding users to the wheel group is bad
and also adding NOPASSWD and ALL = ALL to sudoers for an user is also
plain as bad. The only alternative I can think of at the moment is to
populate the
What exactly are you trying to enable users to do? The fact that you need to
provide normal users with these kind of privileges indicates a possible flaw
in your overall scheme. You may find that, after careful reconsideration,
there are precious few commands that you would actually have to
On 9/15/07, Chris [EMAIL PROTECTED] wrote:
I been looking for ways to let normal user run privileged commands and
after some searching found that adding users to the wheel group is bad
and also adding NOPASSWD and ALL = ALL to sudoers for an user is also
plain as bad. The only alternative I
Does anyone feel it would be useful to add PKG_PATH to the
default env_keep for sudo? Otherwise there are going to be an
awful lot of pkg_add is broken posts...
In message [EMAIL PROTECTED]
so spake Stuart Henderson (stu):
Does anyone feel it would be useful to add PKG_PATH to the
default env_keep for sudo? Otherwise there are going to be an
awful lot of pkg_add is broken posts...
Since that is OpenBSD-specific I don't think it makes sense
Oke, problem solved. But, why doesn't this flag get set implicitly when
using a command with ssh?
Chris Cohen wrote:
On Saturday 30 June 2007 19:31, Tom Van Looy wrote:
Hi
Today I used sudo as command to ssh and it echoed my sudo password.
[EMAIL PROTECTED] ~]
$ ssh soekris sudo pfctl -s
and not to be
noticed. :-D
On 7/1/07, Tom Van Looy [EMAIL PROTECTED] wrote:
Oke, problem solved. But, why doesn't this flag get set implicitly when
using a command with ssh?
Chris Cohen wrote:
On Saturday 30 June 2007 19:31, Tom Van Looy wrote:
Hi
Today I used sudo as command to ssh and it echoed
Tom Van Looy wrote:
Oke, problem solved. But, why doesn't this flag get set implicitly when
using a command with ssh?
Because it's not 8bit-clean, the tty layer can change the data. It's
usually ok for text, but it messes up binary data so having it on all
the time would make ssh pipelines
Hi
Today I used sudo as command to ssh and it echoed my sudo password.
[EMAIL PROTECTED] ~]
$ ssh soekris sudo pfctl -s state
[EMAIL PROTECTED]'s password:
Password:secret_in_echo
output of pfctl /
[EMAIL PROTECTED] ~]
$
I don't see anything about this in the manpage so I think
On Saturday 30 June 2007 19:31, Tom Van Looy wrote:
Hi
Today I used sudo as command to ssh and it echoed my sudo password.
[EMAIL PROTECTED] ~]
$ ssh soekris sudo pfctl -s state
[EMAIL PROTECTED]'s password:
Password:secret_in_echo
output of pfctl /
[EMAIL PROTECTED] ~]
$
I
Tom Van Looy wrote:
Hi
Today I used sudo as command to ssh and it echoed my sudo password.
[EMAIL PROTECTED] ~]
$ ssh soekris sudo pfctl -s state
[EMAIL PROTECTED]'s password:
Password:secret_in_echo
output of pfctl /
[EMAIL PROTECTED] ~]
$
I don't see anything about this in the manpage
Here's the command I used to make the patch as I'm not sure I used the
correct switches :
$ diff -u sudo.8.org sudo.8.new sudo.8.patch
--- sudo.8.org Thu Feb 22 09:58:00 2007
+++ sudo.8.new Thu Feb 22 09:58:43 2007
@@ -593,7 +593,7 @@
\ $ sudo cd /usr/local/protected
.Ve
.PP
-since when
Hi Didier,
Didier Wiroth wrote on Thu, Jan 25, 2007 at 10:52:04AM +0100:
I can't make build with:
nice make SUDO=sudo build
or
nice make SUDO=/usr/bin/sudo build
My mk.conf has the following entries:
SUDO=/usr/bin/sudo
You need not state the same thing twice.
If you define SUDO
You only need write access to the directory to delete files (unless the
sticky bit is set). Make the dir writable by a group the shell script
runs as.
IMHO, this is very bad advice (at least unless you know much more
about the context of Marco's question).
Directory write access is very
hello
i've got a little problem. i have to remove some files in a shell script
that or not owned or writable by the user the shell script runs.
is there a way to give this user write access only to the files needed
to remove by the shell script (with sudo nopasswd)?
thanks and kind regards
Marco Fretz wrote:
hello
i've got a little problem. i have to remove some files in a shell script
that or not owned or writable by the user the shell script runs.
is there a way to give this user write access only to the files needed
to remove by the shell script (with sudo nopasswd
by the user the shell script runs.
is there a way to give this user write access only to the files needed
to remove by the shell script (with sudo nopasswd)?
thanks and kind regards
marco
Marco Fretz wrote:
i've got a little problem. i have to remove some files in a shell script
that or not owned or writable by the user the shell script runs.
is there a way to give this user write access only to the files needed
to remove by the shell script (with sudo nopasswd
of least privilege.
is there a way to give this user write access only to the files
needed to remove by the shell script (with sudo nopasswd)?
An alternative to using `sudo rm` directly might be to write a small
C program calling unlink(2) as needed. You might either install
this program SGID
On 2/11/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Tobias Weingartner wrote:
I'm outa my depth here, but seems that any implementation
of something like sudo that belongs to the shell
is an open invitation to security disasters.
It takes a deliberate act to enable sudo for users
I don't know whether this is or would be considered as a bug,
or whether it is generally known, but sudo, when successfully
invoked with a password in one shell, becomes active in all
shells of that user for the timed duration.
Dave Feustel
--
Lose, v., experience a loss, get rid of, lose
Dave Feustel wrote:
I don't know whether this is or would be considered as a bug,
or whether it is generally known,
Take a look at the tty_tickets option of sudoers(5) and the -k and -K
arguments to sudo(1). Some other operating systems use a default
configuration file that turns
On Sat, 11 Feb 2006, Dave Feustel wrote:
I don't know whether this is or would be considered as a bug,
or whether it is generally known, but sudo, when successfully
invoked with a password in one shell, becomes active in all
shells of that user for the timed duration.
This is pathetic
On Saturday 11 February 2006 10:42, Otto Moerbeek wrote:
On Sat, 11 Feb 2006, Dave Feustel wrote:
I don't know whether this is or would be considered as a bug,
or whether it is generally known, but sudo, when successfully
invoked with a password in one shell, becomes active in all
on sudo.
HTH. HAND
Martin
--
http://www.tm.oneiros.de
On Saturday 11 February 2006 11:04, [EMAIL PROTECTED] wrote:
man sudo for starters.
(actually that's quite enough even for a noob like me)
(even a very out of date linux is enough)
sheesh
Actually --with-tickets is not mentioned in sudo.
(I was sent '--with-tickets' info off-list by a helpful
man sudo for starters.
(actually that's quite enough even for a noob like me)
(even a very out of date linux is enough)
sheesh
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
Dave Feustel
Sent: Saturday, February 11, 2006 9:50 AM
To: Otto Moerbeek
Cc
On Saturday, February 11, Dave Feustel wrote:
I found out via a google search on 'tickets sudo' about
the behavior I had discovered and reported. Then after Otto
let me know how pathetic my post was, I went back to man sudo
but found nothing about tickets or about sudo being active in
all
On Sat, 11 Feb 2006, Dave Feustel wrote:
On Saturday 11 February 2006 11:04, [EMAIL PROTECTED] wrote:
man sudo for starters.
(actually that's quite enough even for a noob like me)
(even a very out of date linux is enough)
sheesh
Actually --with-tickets is not mentioned in sudo.
(I
On Saturday 11 February 2006 12:17, Steve Tornio wrote:
man sudoers
Thanks to all who replied.
I will try hard to be more thorough in the future.
Dave
--
Lose, v., experience a loss, get rid of, lose the weight
Loose, adj., not tight, let go, free, loose clothing
You sudo something, it asks for your password
You do it again soon after, it doesn't ask.
So somehow it remembers you.
Definitely more trouble, and probably opens some holes
for nasties, if it also remembers which version of you.
That's without knowing enough to have an opinion.
-Original
Tobias Weingartner wrote:
On Saturday, February 11, Dave Feustel wrote:
I found out via a google search on 'tickets sudo' about
the behavior I had discovered and reported. Then after Otto
let me know how pathetic my post was, I went back to man sudo
but found nothing about tickets
On 2006-02-11 11:58:29 -0500, Dave Feustel wrote:
all shells. There may be something in the sudo man page that
describes this behavior, but I haven't spotted it yet.
SEE ALSO
grep(1), su(1), stat(2), login_cap(3), sudoers(5),
passwd(5), visudo(8)
My reading skills must
the faster computer so that I can
access them from the slower.
3) sudo make install for each of the patched components.
Of course, OpenBSD versions are exactly the same on both computers.
On Thursday 18 of August 2005 20:12, Nick Holland wrote:
On Thu, Aug 18, 2005 at 04:02:21PM +, Scott Plumlee wrote:
Nick Holland wrote:
snip
and if you could find a REASON you absolutely had to login as root from
a multi-user system, you could always do a sudo su - which will take
you
.
How about using the -c option to sudo(8)? It allows you to specify the
login class limiting the command you want to run.
hmm, 'sudo -c builders make build', nice. But... I am already member of class
'staff', which in login.conf is described:
staff:\
:datasize-cur=75M:\
:datasize
Or maybe put SUDO=sudo -c staff into /etc/mk.conf
and also put yourself (the non-root user) into the wsrc group
2005/8/20, viq [EMAIL PROTECTED]:
hmm, 'sudo -c builders make build', nice. But... I am already
member of class 'staff', which in login.conf is described:
On 8/20/05, viq [EMAIL PROTECTED] wrote:
Actually, I had to log in as root a few times, to build some of the ports.
Well, maybe not _HAD_ to, but i didn't really know how to otherwise allow
user to use more RAM just for the build.
How about using the -c option to sudo(8)? It allows you
to use sudo instead of su - when you want to do something
that requires privileges. Why is this? What settings are you using for sudo?
Thank you!
Tim
101 - 200 of 211 matches
Mail list logo
