Re: migrate python script from sudo to doas

[Markus Rosjat]

Hi Vincent,

Am 03.11.2018 um 07:22 schrieb vincent delft:

Hello Markus,

I cannot reproduce your problem.

As you can see here under I can create a user "test1" on the command line,
and, with the same userid, I can create it with python2 and python3 too.
(I'm running 6.4)

I see 2 possible cause :
- your python script,
- or maybe the userid for which your python script runs is not the one
defined in doas.conf.
i switch back to spawnl function and it worked with doas so I will stick 
with that since it's working. Maybe later I will revisit the problem and 
give it another try.


regards

--
Markus Rosjatfon: +49 351 8107224mail: ros...@ghweb.de

G+H Webservice GbR Gorzolla, Herrmann
Königsbrücker Str. 70, 01099 Dresden

http://www.ghweb.de
fon: +49 351 8107220   fax: +49 351 8107227

Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before you 
print it, think about your responsibility and commitment to the ENVIRONMENT

Re: migrate python script from sudo to doas

[vincent delft]

Hello Markus,

I cannot reproduce your problem.

As you can see here under I can create a user "test1" on the command line,
and, with the same userid, I can create it with python2 and python3 too.
(I'm running 6.4)

I see 2 possible cause :
- your python script,
- or maybe the userid for which your python script runs is not the one
defined in doas.conf.

regards



The python script I use is:
"
import subprocess

cmd = "doas useradd -u 9003 -g=uid -s /sbin/nologin -d /tmp test3"
cmd_list = cmd.split()
exit = subprocess.check_call(cmd_list)
"

the tests results are:
"
obsd-laptop:~$ doas useradd -u 9001 -g=uid -s /sbin/nologin -d /tmp test1
obsd-laptop:~$ echo $?
0

obsd-laptop:~$ python2.7
test.py
obsd-laptop:~$ echo $?
0
obsd-laptop:~$ userinfo test2
login   test2
passwd  *
uid 9002
groups  test2
change  NEVER
class
gecos
dir /tmp
shell   /sbin/nologin
expire  NEVER
obsd-laptop:~$ python3.6
test.py
obsd-laptop:~$ echo $?
0
obsd-laptop:~$ userinfo test3
login   test3
passwd  *
uid 9003
groups  test3
change  NEVER
class
gecos
dir /tmp
shell   /sbin/nologin
expire  NEVER
"






On Tue, Oct 30, 2018 at 1:22 PM Markus Rosjat  wrote:

> Hi,
>
> as I stated before on a cmd is no problem, Im using 6.4 release
>
>
> Am 30.10.2018 um 12:56 schrieb Solene Rapenne:
> > Markus Rosjat  wrote:
> >> hi all,
> >>
> >> I have some old python scripts that using os.spawnl to execute stuff
> >> like useradd  combined with sudo. This worked just fine on systems with
> >> sudo installed  but these days we have doas and its totally enough for
> >> things I use to do so I said to myself "lets update these old scripts
> >> ..." . In code this was basically replasing os.spawnl with
> >> subprocess.check_call  but when I run this the useradd command doesnt
> >> get executed by the script. On the cmd it does, so this works on cmd:
> >>
> >> doas useradd -u 666 -g =uid -s /sbin/nologin -d
> >> /var/mail/domain.tld/vmailuser0666 vmailuser0666
> >>
> >> but in the script I with the code like this:
> >>
> >>exit = subprocess.check_call(['doas', 'useradd', '-u %s' % user_id,
> >> '-g =uid',
> >> '-s /sbin/nologin',
> >> '-d %s' % mb_parent_dir,
> >> user_name])
> >>
> >> I get an exception that seems to be related to the fact that doas isnt
> >> really working here
> >>
> >> doas: Authorization failed <- this comes from the script even the
> >> provided password is correct
> >>
> >> Traceback (most recent call last):
> >> File "/root/scripts/mb_add", line 244, in 
> >>   mb_addresses)
> >> File "/root/scripts/mb_add", line 174, in add_mailbox
> >>   user_name])
> >> File "/usr/local/lib/python2.7/subprocess.py", line 190, in
> check_call
> >>   raise CalledProcessError(retcode, cmd)
> >> subprocess.CalledProcessError: Command '['doas', 'useradd', '-u 666',
> >> '-g =uid', '-s /sbin/nologin', '-d /var/mail/domain.tld/vmailuser666',
> >> 'vmailuser666']' returned non-zero exit status 1
> >>
> >> So does someone had some issues with migrating scripts from sudo to
> >> doas, then some help or hintw would be very appreciated.
> >>
> >>
> >> regards
> > hi
> >
> > what openbsd version are you using?
> > did you try the command outside of python?
> >
> > There were issues with doas a few days ago in snapshots.
> >
>
> --
> Markus Rosjatfon: +49 351 8107224mail: ros...@ghweb.de
>
> G+H Webservice GbR Gorzolla, Herrmann
> Königsbrücker Str. 70, 01099 Dresden
>
> http://www.ghweb.de
> fon: +49 351 8107220   fax: +49 351 8107227
>
> Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before
> you print it, think about your responsibility and commitment to the
> ENVIRONMENT
>
>

Re: migrate python script from sudo to doas

[Markus Rosjat]

Hi Vincent


Am 30.10.2018 um 16:03 schrieb Vincent Legoll:

Maybe you should try like the following:

cmd = ['doas', 'useradd',
   '-u', user_id,
   '-g', '=uid',
   '-s', '/sbin/nologin',
   '-d', mb_parent_dir,
   user_name]
exit = subprocess.check_call(cmd)



this doesn't solve the problem, if I try like that check_call complains 
that it need a string as user_id. If I do make something like


u_id = '%s' %user_id and plug u_id as the arg I'm back to square one. So 
it seems this seems a doas related issue and needs some adjustment in 
doas.conf. If this isnt resolvable I will just install sudo package 
using the "pointing a cannon at a sparrow" approach :(


regards

--
Markus Rosjatfon: +49 351 8107224mail: ros...@ghweb.de

G+H Webservice GbR Gorzolla, Herrmann
Königsbrücker Str. 70, 01099 Dresden

http://www.ghweb.de
fon: +49 351 8107220   fax: +49 351 8107227

Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before you 
print it, think about your responsibility and commitment to the ENVIRONMENT

Re: migrate python script from sudo to doas

[Vincent Legoll]

Hello,

On Tue, Oct 30, 2018 at 12:33 PM Markus Rosjat  wrote:
>   exit = subprocess.check_call(['doas', 'useradd', '-u %s' % user_id,
> '-g =uid',
> '-s /sbin/nologin',
> '-d %s' % mb_parent_dir,
> user_name])

Maybe you should try like the following:

cmd = ['doas', 'useradd',
  '-u', user_id,
  '-g', '=uid',
  '-s', '/sbin/nologin',
  '-d', mb_parent_dir,
  user_name]
exit = subprocess.check_call(cmd)

Re: migrate python script from sudo to doas

[Markus Rosjat]

Hi,

as I stated before on a cmd is no problem, Im using 6.4 release


Am 30.10.2018 um 12:56 schrieb Solene Rapenne:

Markus Rosjat  wrote:

hi all,

I have some old python scripts that using os.spawnl to execute stuff
like useradd  combined with sudo. This worked just fine on systems with
sudo installed  but these days we have doas and its totally enough for
things I use to do so I said to myself "lets update these old scripts
..." . In code this was basically replasing os.spawnl with
subprocess.check_call  but when I run this the useradd command doesnt
get executed by the script. On the cmd it does, so this works on cmd:

doas useradd -u 666 -g =uid -s /sbin/nologin -d
/var/mail/domain.tld/vmailuser0666 vmailuser0666

but in the script I with the code like this:

   exit = subprocess.check_call(['doas', 'useradd', '-u %s' % user_id,
'-g =uid',
'-s /sbin/nologin',
'-d %s' % mb_parent_dir,
user_name])

I get an exception that seems to be related to the fact that doas isnt
really working here

doas: Authorization failed <- this comes from the script even the
provided password is correct

Traceback (most recent call last):
    File "/root/scripts/mb_add", line 244, in 
      mb_addresses)
    File "/root/scripts/mb_add", line 174, in add_mailbox
      user_name])
    File "/usr/local/lib/python2.7/subprocess.py", line 190, in check_call
      raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['doas', 'useradd', '-u 666',
'-g =uid', '-s /sbin/nologin', '-d /var/mail/domain.tld/vmailuser666',
'vmailuser666']' returned non-zero exit status 1

So does someone had some issues with migrating scripts from sudo to
doas, then some help or hintw would be very appreciated.


regards

hi

what openbsd version are you using?
did you try the command outside of python?

There were issues with doas a few days ago in snapshots.



--
Markus Rosjatfon: +49 351 8107224mail: ros...@ghweb.de

G+H Webservice GbR Gorzolla, Herrmann
Königsbrücker Str. 70, 01099 Dresden

http://www.ghweb.de
fon: +49 351 8107220   fax: +49 351 8107227

Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before you 
print it, think about your responsibility and commitment to the ENVIRONMENT

Re: migrate python script from sudo to doas

[Solene Rapenne]

Markus Rosjat  wrote:
> hi all,
> 
> I have some old python scripts that using os.spawnl to execute stuff 
> like useradd  combined with sudo. This worked just fine on systems with 
> sudo installed  but these days we have doas and its totally enough for 
> things I use to do so I said to myself "lets update these old scripts 
> ..." . In code this was basically replasing os.spawnl with 
> subprocess.check_call  but when I run this the useradd command doesnt 
> get executed by the script. On the cmd it does, so this works on cmd:
> 
> doas useradd -u 666 -g =uid -s /sbin/nologin -d 
> /var/mail/domain.tld/vmailuser0666 vmailuser0666
> 
> but in the script I with the code like this:
> 
>   exit = subprocess.check_call(['doas', 'useradd', '-u %s' % user_id,
> '-g =uid',
> '-s /sbin/nologin',
> '-d %s' % mb_parent_dir,
> user_name])
> 
> I get an exception that seems to be related to the fact that doas isnt 
> really working here
> 
> doas: Authorization failed <- this comes from the script even the 
> provided password is correct
> 
> Traceback (most recent call last):
>    File "/root/scripts/mb_add", line 244, in 
>      mb_addresses)
>    File "/root/scripts/mb_add", line 174, in add_mailbox
>      user_name])
>    File "/usr/local/lib/python2.7/subprocess.py", line 190, in check_call
>      raise CalledProcessError(retcode, cmd)
> subprocess.CalledProcessError: Command '['doas', 'useradd', '-u 666', 
> '-g =uid', '-s /sbin/nologin', '-d /var/mail/domain.tld/vmailuser666', 
> 'vmailuser666']' returned non-zero exit status 1
> 
> So does someone had some issues with migrating scripts from sudo to 
> doas, then some help or hintw would be very appreciated.
> 
> 
> regards

hi

what openbsd version are you using?
did you try the command outside of python?

There were issues with doas a few days ago in snapshots.

migrate python script from sudo to doas

[Markus Rosjat]

hi all,

I have some old python scripts that using os.spawnl to execute stuff 
like useradd  combined with sudo. This worked just fine on systems with 
sudo installed  but these days we have doas and its totally enough for 
things I use to do so I said to myself "lets update these old scripts 
..." . In code this was basically replasing os.spawnl with 
subprocess.check_call  but when I run this the useradd command doesnt 
get executed by the script. On the cmd it does, so this works on cmd:


doas useradd -u 666 -g =uid -s /sbin/nologin -d 
/var/mail/domain.tld/vmailuser0666 vmailuser0666


but in the script I with the code like this:

 exit = subprocess.check_call(['doas', 'useradd', '-u %s' % user_id,
'-g =uid',
'-s /sbin/nologin',
'-d %s' % mb_parent_dir,
user_name])

I get an exception that seems to be related to the fact that doas isnt 
really working here


doas: Authorization failed <- this comes from the script even the 
provided password is correct


Traceback (most recent call last):
  File "/root/scripts/mb_add", line 244, in 
    mb_addresses)
  File "/root/scripts/mb_add", line 174, in add_mailbox
    user_name])
  File "/usr/local/lib/python2.7/subprocess.py", line 190, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['doas', 'useradd', '-u 666', 
'-g =uid', '-s /sbin/nologin', '-d /var/mail/domain.tld/vmailuser666', 
'vmailuser666']' returned non-zero exit status 1


So does someone had some issues with migrating scripts from sudo to 
doas, then some help or hintw would be very appreciated.



regards

--
Markus Rosjatfon: +49 351 8107224mail: ros...@ghweb.de

G+H Webservice GbR Gorzolla, Herrmann
Königsbrücker Str. 70, 01099 Dresden

http://www.ghweb.de
fon: +49 351 8107220   fax: +49 351 8107227

Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before you 
print it, think about your responsibility and commitment to the ENVIRONMENT

Re: sudoreplay in sudo 1.8.21 on 6.2-snapshot

[Todd C. Miller]

This is fixed in sudo 1.8.21p1.  It's in ports now but you'll need
to wait a bit for a prebuild package, though you can of course
build your own.

 - todd

Re: sudoreplay in sudo 1.8.21 on 6.2-snapshot

[Todd C. Miller]

The sudoreplay event loop was rewritten in 1.8.21.  The bug only
occurs when logging input as well as output.  I've reproduced this
now and will debug it later today.

 - todd

sudoreplay in sudo 1.8.21 on 6.2-snapshot

[David A. Pocock]

Using sudoreplay with log_input and log_output on OpenBSD I recently 
encountered:

After updating to sudo-1.8.21 today when I do "sudoreplay " the 
session 
begins but does not proceed to the next screens. 

Last worked in sudo-1.8.20p2 still works fine.

I've tried this with sudoreplay -R also. The symptom persists.

Sessions created in 1.8.21 or 1.8.20 I cannot play back using 1.8.21.
Sessions created in 1.8.21 or 1.8.20 I canplay back using 1.8.20.

Tested on:
OpenBSD maleah.dayid.org 6.2 GENERIC.MP#101 i386
$ sudo -V
Sudo version 1.8.21

I've been able to consistently recreate by attempting to sudoreplay any 
session. 

Is there any further useful information I may provide to investigate such 
behavior?

-David A. Pocock

Re: pkg_mgr, ntfs_3g, sudo, partition access.

[Ron Georgia]

Mohammad,

On Sat, Apr 23, 2016 at 08:59:41AM -0500, Edgar Pettijohn wrote:
> man disklabel
>
To find your DUID use doas disklabel sd1. You will have a multiline
output with one line similar to: duid: 3e35f72eb60d84ba. That is what
you will use in your /etc/fstab.
However I would strongly recommend reading the man page. I find having
the man page in a readable, scrollable format helpful. Check out
http://man.openbsd.org/?query=disklabel.
Also the FAQ is very helpful. http://www.openbsd.org/faq/faq14.html
 
> Scroll down to the first example.
> 
> Sent from my iPhone
> 
> > On Apr 23, 2016, at 8:08 AM, Mohammad BadieZadegan 
> wrote:
> >
> > Thanks Paul, It's resolve my issue! Bravo.
> > Thanks ludovic, I had bad chance in network speed at that time and when I
> > repeat your command it resolve my issue!
> > Dear Chris,
> > I have 2 other partitions other than my OpenBSD and I don't know my HDD
> > partitions IDs to append in my fstab! How can I know that?
> >
> > Regards to All.
> >
> > On Sat, Apr 23, 2016 at 8:08 PM, Paul Irofti  wrote:
> >
> >>> 2. I installed ntfs_3g but still I can not write over ntfs flash usb! How
> >>> can I do that?
> >>
> >> Are you using the mount(8) command? Do not! Use ntfs-3g(8).
> >
> >
> >
> > --
> > [image: ( openbsd.pro  933k.ir )] 
>

I'm new to participating in the mailing list AND to using mutt, so
forgive me if I step into the wrong sandbox. 

Re: pkg_mgr, ntfs_3g, sudo, partition access.

[Edgar Pettijohn]

man disklabel

Scroll down to the first example.

Sent from my iPhone

> On Apr 23, 2016, at 8:08 AM, Mohammad BadieZadegan 
wrote:
>
> Thanks Paul, It's resolve my issue! Bravo.
> Thanks ludovic, I had bad chance in network speed at that time and when I
> repeat your command it resolve my issue!
> Dear Chris,
> I have 2 other partitions other than my OpenBSD and I don't know my HDD
> partitions IDs to append in my fstab! How can I know that?
>
> Regards to All.
>
> On Sat, Apr 23, 2016 at 8:08 PM, Paul Irofti  wrote:
>
>>> 2. I installed ntfs_3g but still I can not write over ntfs flash usb! How
>>> can I do that?
>>
>> Are you using the mount(8) command? Do not! Use ntfs-3g(8).
>
>
>
> --
> [image: ( openbsd.pro  933k.ir )] 

Re: pkg_mgr, ntfs_3g, sudo, partition access.

[Mohammad BadieZadegan]

Thanks Paul, It's resolve my issue! Bravo.
Thanks ludovic, I had bad chance in network speed at that time and when I
repeat your command it resolve my issue!
Dear Chris,
I have 2 other partitions other than my OpenBSD and I don't know my HDD
partitions IDs to append in my fstab! How can I know that?

Regards to All.

On Sat, Apr 23, 2016 at 8:08 PM, Paul Irofti  wrote:

> > 2. I installed ntfs_3g but still I can not write over ntfs flash usb! How
> > can I do that?
>
> Are you using the mount(8) command? Do not! Use ntfs-3g(8).
>



-- 
[image: ( openbsd.pro  933k.ir )] 

Re: pkg_mgr, ntfs_3g, sudo, partition access.

[Paul Irofti]

> 2. I installed ntfs_3g but still I can not write over ntfs flash usb! How
> can I do that?

Are you using the mount(8) command? Do not! Use ntfs-3g(8).

Re: pkg_mgr, ntfs_3g, sudo, partition access.

[Chris Bennett]

On Sat, Apr 23, 2016 at 02:52:37PM +0430, Mohammad BadieZadegan wrote:
> 3. How can I access to my other HDD partitions?
> Best Regards,
> 

You can edit the /etc/fstab file to also mount those other partitions
onto directories you create on the boot drive. This will happen when
booting.

mkdir /cool_other_drive_home
mkdir /lousy_other_drive_mp3s

you don't need to use the original names on the other hard drive, for
example, you can't have two /home folders
So, /cool_other_drive_home was the /home folder on the other drive.

21358ebbfcf8089c.b none swap sw
21358ebbfcf8089c.a / ffs rw 1 1
21358ebbfcf8089c.j /altroot ffs xx 0 0
21358ebbfcf8089c.d /tmp ffs rw,nodev,nosuid 1 2
21358ebbfcf8089c.f /usr ffs ro,nodev 1 2
21358ebbfcf8089c.g /usr/X11R6 ffs ro,nodev 1 2
21358ebbfcf8089c.h /usr/local ffs ro,nodev 1 2
21358ebbfcf8089c.e /var ffs rw,nodev,nosuid 1 2
2ba6d152d8b5c562.m /home ffs rw,nodev,nosuid 1 2
2ba6d152d8b5c562.n /cool_other_drive_home ffs rw,nodev,nosuid 1 2
2ba6d152d8b5c562.k /lousy_other_drive_mp3s ffs ro,nodev,nosuid 1 2

One caveat, if you do this, you must always have both drives present!
man fstab and man mount will be helpful.

Above is almost exactly what I use myself. Boot off of a small USB drive
and we have home folders on another 2TB USB drive.

Look at how I have some partitions marked ro (read-only) and rw (read
and write). This is very helpful when the system crashes and fsck is run
on reboot. Those partions are always left clean.

In the above, notice how I have prevented anyone from writing any more
lousy mp3s to that partition.

If drives are coming and going, you will need to manually mount and
umount them. Still need to create those directories first.

Chris Bennett

Re: pkg_mgr, ntfs_3g, sudo, partition access.

[ludovic coues]

2016-04-23 12:22 GMT+02:00 Mohammad BadieZadegan <mbzade...@gmail.com>:
> Hi everybody,
> I have installed OpenBSD5.9 on my HDD last partition successfully.
> I have 3 questions about this latest release after reading the OpenBSD FAQ
> page,
> 1. How can I install pkg_mgr, sudo, as older releases?
> 2. I installed ntfs_3g but still I can not write over ntfs flash usb! How
> can I do that?
> 3. How can I access to my other HDD partitions?
> Best Regards,
>

To answer question 1, pkg_mgr and sudo are available as port.
`# pkg_add sudo pkg_mgr` should be enough to install both.
In case you missed it, doas is an alternative to sudo.

-- 

Cordialement, Coues Ludovic
+336 148 743 42

pkg_mgr, ntfs_3g, sudo, partition access.

[Mohammad BadieZadegan]

Hi everybody,
I have installed OpenBSD5.9 on my HDD last partition successfully.
I have 3 questions about this latest release after reading the OpenBSD FAQ
page,
1. How can I install pkg_mgr, sudo, as older releases?
2. I installed ntfs_3g but still I can not write over ntfs flash usb! How
can I do that?
3. How can I access to my other HDD partitions?
Best Regards,

Re: sudo and globbing

[Jiri B]

On Fri, Jan 08, 2016 at 12:04:15PM +0200, Alexey Kurinnij wrote:
> And what about difference? Explain please.
> 
> > > I discovered an article about sudo and globbing[1] and
> > > there's difference how it does work on Linux and OpenBSD.
> >
> > http://zurlinux.com/?p=2244
> >
> > > - openbsd
> > >
> > > # su -s /usr/local/bin/bash - nobody
> > > No home directory /nonexistent!
> > > Logging in with home = "/".
> > > -bash-4.3$ sudo bash -c "ls -l /var/tor/cache*"
> > > -rw---  1 _tor  _tor20442 Dec 10 11:32 /var/tor/cached-certs
> > > -rw---  1 _tor  _tor  1409287 Jan  7 15:56
> > /var/tor/cached-microdesc-consensus
> > > -rw---  1 _tor  _tor  5107307 Jan  7 17:23 /var/tor/cached-microdescs
> > > -rw---  1 _tor  _tor0 Jan  7 17:23
> > /var/tor/cached-microdescs.new
> > > -bash-4.3$ sudo -s bash -c "ls -l /var/tor/cache*"
> > > .cshrc   .profile altroot  bin  bsd  bsd.rd   bsd.sp   dev
> > etc  home mnt  root sbin sys  tftpboot tmp
> > usr  var

^^^ here '*' gets expanded inside original user's shell.

> > > - linux
> > >
> > > [root@slot-1 ~]# su -s /bin/bash nobody
> > > bash-4.2$ sudo bash -c "ls -l /var/cache/ldconfig/aux*"
> > > -rw---. 1 root root 26470 Dec 22 17:52 /var/cache/ldconfig/aux-cache
> > > bash-4.2$ sudo -s bash -c "ls -l /var/cache/ldconfig/aux*"
> > > -rw---. 1 root root 26470 Dec 22 17:52 /var/cache/ldconfig/aux-cache

^^^ here '*' gets expanded probably later, as original user does
not have access to /var/cache/ldconfig at all.

In both cases original user does not have access to /var/tor, respecively
to /var/cache/ldconfig.

So the question is: why does same command on equally "restricted" dir
path gets different output - why on openbsd does '*' get expanded
immediatelly but on linux is it taken into account somehow by sudo (?)...

j.

Re: sudo and globbing

[Peter Hessler]

On 2016 Jan 08 (Fri) at 05:52:32 -0500 (-0500), Jiri B wrote:
:On Fri, Jan 08, 2016 at 12:04:15PM +0200, Alexey Kurinnij wrote:
:> And what about difference? Explain please.
:> 
:> > > I discovered an article about sudo and globbing[1] and
:> > > there's difference how it does work on Linux and OpenBSD.
:> >
:> > http://zurlinux.com/?p=2244
:> >
:> > > - openbsd
:> > >
:> > > # su -s /usr/local/bin/bash - nobody
:> > > No home directory /nonexistent!
:> > > Logging in with home = "/".
:> > > -bash-4.3$ sudo bash -c "ls -l /var/tor/cache*"
:> > > -rw---  1 _tor  _tor20442 Dec 10 11:32 /var/tor/cached-certs
:> > > -rw---  1 _tor  _tor  1409287 Jan  7 15:56
:> > /var/tor/cached-microdesc-consensus
:> > > -rw---  1 _tor  _tor  5107307 Jan  7 17:23 /var/tor/cached-microdescs
:> > > -rw---  1 _tor  _tor0 Jan  7 17:23
:> > /var/tor/cached-microdescs.new
:> > > -bash-4.3$ sudo -s bash -c "ls -l /var/tor/cache*"
:> > > .cshrc   .profile altroot  bin  bsd  bsd.rd   bsd.sp   dev
:> > etc  home mnt  root sbin     sys  tftpboot tmp
:> > usr  var
:
:^^^ here '*' gets expanded inside original user's shell.
:
:> > > - linux
:> > >
:> > > [root@slot-1 ~]# su -s /bin/bash nobody
:> > > bash-4.2$ sudo bash -c "ls -l /var/cache/ldconfig/aux*"
:> > > -rw---. 1 root root 26470 Dec 22 17:52 /var/cache/ldconfig/aux-cache
:> > > bash-4.2$ sudo -s bash -c "ls -l /var/cache/ldconfig/aux*"
:> > > -rw---. 1 root root 26470 Dec 22 17:52 /var/cache/ldconfig/aux-cache
:
:^^^ here '*' gets expanded probably later, as original user does
:not have access to /var/cache/ldconfig at all.
:
:In both cases original user does not have access to /var/tor, respecively
:to /var/cache/ldconfig.
:
:So the question is: why does same command on equally "restricted" dir
:path gets different output - why on openbsd does '*' get expanded
:immediatelly but on linux is it taken into account somehow by sudo (?)...
:
:j.
:

$ ls -l /var/spool/smtpd/* | head 
ls: /var/spool/smtpd/*: No such file or directory
$ ls -l /var/spool/smtpd  
ls: smtpd: Permission denied
$ doas bash -c "ls -l /var/spool/smtpd/*" | head 
/var/spool/smtpd/corrupt:

/var/spool/smtpd/incoming:

/var/spool/smtpd/offline:

/var/spool/smtpd/purge:
total 352
drwx--  2 _smtpq  wheel  512 Jan 14  2015 1040272804
drwx--  2 _smtpq  wheel  512 Jan 14  2015 1056615683
$ sudo bash -c "ls -l /var/spool/smtpd/*" | head 
/var/spool/smtpd/corrupt:

/var/spool/smtpd/incoming:

/var/spool/smtpd/offline:

/var/spool/smtpd/purge:
total 352
drwx--  2 _smtpq  wheel  512 Jan 14  2015 1040272804
drwx--  2 _smtpq  wheel  512 Jan 14  2015 1056615683
$ uname -a
OpenBSD dante.berlin.hsgate.de 5.9 GENERIC.MP#2 amd64


I can't reproduce your failure on -current.  I'm assuming there was some
spaces or quotation failures when you generated your example.


-- 
"A radioactive cat has eighteen half-lives."

Re: sudo and globbing

[Eric Furman]

There are so many differences between Linux and every other flavour of
UNIX;
like OpenBSD, AIX, Solaris, etc, that WTF is your point??
Really?
What about Gnu's Not UNIX don't you get?
This crap is just trolling, IMHO.

On Fri, Jan 8, 2016, at 09:27 AM, Alexander Hall wrote:
> On January 8, 2016 11:52:32 AM GMT+01:00, Jiri B <ji...@devio.us> wrote:
> >On Fri, Jan 08, 2016 at 12:04:15PM +0200, Alexey Kurinnij wrote:
> >> And what about difference? Explain please.
> >> 
> >> > > I discovered an article about sudo and globbing[1] and
> >> > > there's difference how it does work on Linux and OpenBSD.
> >> >
> >> > http://zurlinux.com/?p=2244
> >> >
> >> > > - openbsd
> >> > >
> >> > > # su -s /usr/local/bin/bash - nobody
> >> > > No home directory /nonexistent!
> >> > > Logging in with home = "/".
> >> > > -bash-4.3$ sudo bash -c "ls -l /var/tor/cache*"
> >> > > -rw---  1 _tor  _tor20442 Dec 10 11:32
> >/var/tor/cached-certs
> >> > > -rw---  1 _tor  _tor  1409287 Jan  7 15:56
> >> > /var/tor/cached-microdesc-consensus
> >> > > -rw---  1 _tor  _tor  5107307 Jan  7 17:23
> >/var/tor/cached-microdescs
> >> > > -rw---  1 _tor  _tor0 Jan  7 17:23
> >> > /var/tor/cached-microdescs.new
> >> > > -bash-4.3$ sudo -s bash -c "ls -l /var/tor/cache*"
> >> > > .cshrc   .profile altroot  bin  bsd  bsd.rd   bsd.sp  
> >dev
> >> > etc  home mnt  root sbin sys  tftpboot tmp
> >> > usr  var
> >
> >^^^ here '*' gets expanded inside original user's shell.
> 
> I see no way that glob would result in the contents of the root
> directory. 
> 
> Here's my guess: everything after -s is concatenated and whitespace
> separated, effectively turning the example into 
> 
> bash -c ls -l /var/tor/cache*
> 
> Thus, start bash and ask it to run "ls". Also pass "-l" and
> /var/tor/cache* as $0, $1... The latter of which is pretty pointless. 
> 
> Thus could be a matter of different default configurations between $LINUX
> and openbsd. 
> 
> /Alexander 
> 
> >
> >> > > - linux
> >> > >
> >> > > [root@slot-1 ~]# su -s /bin/bash nobody
> >> > > bash-4.2$ sudo bash -c "ls -l /var/cache/ldconfig/aux*"
> >> > > -rw---. 1 root root 26470 Dec 22 17:52
> >/var/cache/ldconfig/aux-cache
> >> > > bash-4.2$ sudo -s bash -c "ls -l /var/cache/ldconfig/aux*"
> >> > > -rw---. 1 root root 26470 Dec 22 17:52
> >/var/cache/ldconfig/aux-cache
> >
> >^^^ here '*' gets expanded probably later, as original user does
> >not have access to /var/cache/ldconfig at all.
> >
> >In both cases original user does not have access to /var/tor,
> >respecively
> >to /var/cache/ldconfig.
> >
> >So the question is: why does same command on equally "restricted" dir
> >path gets different output - why on openbsd does '*' get expanded
> >immediatelly but on linux is it taken into account somehow by sudo
> >(?)...
> >
> >j.

Re: sudo and globbing

[Alexey Kurinnij]

And what about difference? Explain please.

On Thu, Jan 7, 2016 at 7:03 PM, Jiri B <ji...@devio.us> wrote:

> On Thu, Jan 07, 2016 at 11:43:14AM -0500, Jiri B wrote:
> > I discovered an article about sudo and globbing[1] and
> > there's difference how it does work on Linux and OpenBSD.
>
> I forgot to put the url
>
> http://zurlinux.com/?p=2244
>
> > - openbsd
> >
> > # su -s /usr/local/bin/bash - nobody
> > No home directory /nonexistent!
> > Logging in with home = "/".
> > -bash-4.3$ sudo bash -c "ls -l /var/tor/cache*"
> > -rw---  1 _tor  _tor20442 Dec 10 11:32 /var/tor/cached-certs
> > -rw---  1 _tor  _tor  1409287 Jan  7 15:56
> /var/tor/cached-microdesc-consensus
> > -rw---  1 _tor  _tor  5107307 Jan  7 17:23 /var/tor/cached-microdescs
> > -rw---  1 _tor  _tor0 Jan  7 17:23
> /var/tor/cached-microdescs.new
> > -bash-4.3$ sudo -s bash -c "ls -l /var/tor/cache*"
> > .cshrc   .profile altroot  bin  bsd  bsd.rd   bsd.sp   dev
> etc  home mnt  root sbin sys  tftpboot tmp
> usr  var
> >
> > - linux
> >
> > [root@slot-1 ~]# su -s /bin/bash nobody
> > bash-4.2$ exit
> > [root@slot-1 ~]# visudo
> > [root@slot-1 ~]# su -s /bin/bash nobody
> > bash-4.2$ sudo bash -c "ls -l /var/cache/ldconfig/aux*"
> > -rw---. 1 root root 26470 Dec 22 17:52 /var/cache/ldconfig/aux-cache
> > bash-4.2$ sudo -s bash -c "ls -l /var/cache/ldconfig/aux*"
> > -rw---. 1 root root 26470 Dec 22 17:52 /var/cache/ldconfig/aux-cache

Re: sudo and globbing

[Raf Czlonka]

On Thu, Jan 07, 2016 at 04:43:14PM GMT, Jiri B wrote:
> I discovered an article about sudo and globbing[1] and
> there's difference how it does work on Linux and OpenBSD.

AFAIK, globbing is done by shell and sudo doesn't take part in it.

> # su -s /usr/local/bin/bash - nobody
  ^
> [root@slot-1 ~]# su -s /bin/bash nobody
> [...]
> Could anybody explain the difference?

One thing I can see is that on OpenBSD, you run bash as a login shell
but not on Linux.

My guess is that your bash login shell options, or globbing options
between the systems in general, are the cause of the above.

Regards,

Raf

Re: sudo and globbing

[ludovic coues]

2016-01-08 11:52 GMT+01:00 Jiri B <ji...@devio.us>:
>
> So the question is: why does same command on equally "restricted" dir
> path gets different output - why on openbsd does '*' get expanded
> immediatelly but on linux is it taken into account somehow by sudo (?)...
>
> j.
>

you put a dash between the shell and the user in the command on
openbsd. You didn't put that dash on linux.

Re: sudo and globbing

[Alexander Hall]

On January 8, 2016 11:52:32 AM GMT+01:00, Jiri B <ji...@devio.us> wrote:
>On Fri, Jan 08, 2016 at 12:04:15PM +0200, Alexey Kurinnij wrote:
>> And what about difference? Explain please.
>> 
>> > > I discovered an article about sudo and globbing[1] and
>> > > there's difference how it does work on Linux and OpenBSD.
>> >
>> > http://zurlinux.com/?p=2244
>> >
>> > > - openbsd
>> > >
>> > > # su -s /usr/local/bin/bash - nobody
>> > > No home directory /nonexistent!
>> > > Logging in with home = "/".
>> > > -bash-4.3$ sudo bash -c "ls -l /var/tor/cache*"
>> > > -rw---  1 _tor  _tor20442 Dec 10 11:32
>/var/tor/cached-certs
>> > > -rw---  1 _tor  _tor  1409287 Jan  7 15:56
>> > /var/tor/cached-microdesc-consensus
>> > > -rw---  1 _tor  _tor  5107307 Jan  7 17:23
>/var/tor/cached-microdescs
>> > > -rw---  1 _tor  _tor0 Jan  7 17:23
>> > /var/tor/cached-microdescs.new
>> > > -bash-4.3$ sudo -s bash -c "ls -l /var/tor/cache*"
>> > > .cshrc   .profile altroot  bin  bsd  bsd.rd   bsd.sp  
>dev
>> > etc  home mnt  root sbin sys  tftpboot tmp
>> > usr  var
>
>^^^ here '*' gets expanded inside original user's shell.

I see no way that glob would result in the contents of the root directory. 

Here's my guess: everything after -s is concatenated and whitespace separated, 
effectively turning the example into 

bash -c ls -l /var/tor/cache*

Thus, start bash and ask it to run "ls". Also pass "-l" and /var/tor/cache* as 
$0, $1... The latter of which is pretty pointless. 

Thus could be a matter of different default configurations between $LINUX and 
openbsd. 

/Alexander 

>
>> > > - linux
>> > >
>> > > [root@slot-1 ~]# su -s /bin/bash nobody
>> > > bash-4.2$ sudo bash -c "ls -l /var/cache/ldconfig/aux*"
>> > > -rw---. 1 root root 26470 Dec 22 17:52
>/var/cache/ldconfig/aux-cache
>> > > bash-4.2$ sudo -s bash -c "ls -l /var/cache/ldconfig/aux*"
>> > > -rw---. 1 root root 26470 Dec 22 17:52
>/var/cache/ldconfig/aux-cache
>
>^^^ here '*' gets expanded probably later, as original user does
>not have access to /var/cache/ldconfig at all.
>
>In both cases original user does not have access to /var/tor,
>respecively
>to /var/cache/ldconfig.
>
>So the question is: why does same command on equally "restricted" dir
>path gets different output - why on openbsd does '*' get expanded
>immediatelly but on linux is it taken into account somehow by sudo
>(?)...
>
>j.

Re: sudo and globbing

[Todd C. Miller]

You are comparing two very different versions of sudo.  The sudo
that used to ship with OpenBSD is version 1.7.2p8 which is rather
ancient.  On Linux you probably have some variant of sudo 1.8.x.
Newer versions of sudo escape spaces in the command run via "sudo
-s" whereas the ancient 1.7.2p8 does not.  That probably explains
the difference.

If you install sudo from ports you will get the same behavior you
see on linux.

 - todd

Re: sudo and globbing

[Jiri B]

On Thu, Jan 07, 2016 at 11:43:14AM -0500, Jiri B wrote:
> I discovered an article about sudo and globbing[1] and
> there's difference how it does work on Linux and OpenBSD.

I forgot to put the url

http://zurlinux.com/?p=2244

> - openbsd
> 
> # su -s /usr/local/bin/bash - nobody
> No home directory /nonexistent!
> Logging in with home = "/".
> -bash-4.3$ sudo bash -c "ls -l /var/tor/cache*"
> -rw---  1 _tor  _tor20442 Dec 10 11:32 /var/tor/cached-certs
> -rw---  1 _tor  _tor  1409287 Jan  7 15:56 
> /var/tor/cached-microdesc-consensus
> -rw---  1 _tor  _tor  5107307 Jan  7 17:23 /var/tor/cached-microdescs
> -rw---  1 _tor  _tor0 Jan  7 17:23 /var/tor/cached-microdescs.new
> -bash-4.3$ sudo -s bash -c "ls -l /var/tor/cache*"
> .cshrc   .profile altroot  bin  bsd  bsd.rd   bsd.sp   dev  etc   
>home mnt  root sbin sys  tftpboot tmp  usr  var
> 
> - linux
> 
> [root@slot-1 ~]# su -s /bin/bash nobody
> bash-4.2$ exit
> [root@slot-1 ~]# visudo
> [root@slot-1 ~]# su -s /bin/bash nobody
> bash-4.2$ sudo bash -c "ls -l /var/cache/ldconfig/aux*"
> -rw---. 1 root root 26470 Dec 22 17:52 /var/cache/ldconfig/aux-cache
> bash-4.2$ sudo -s bash -c "ls -l /var/cache/ldconfig/aux*"
> -rw---. 1 root root 26470 Dec 22 17:52 /var/cache/ldconfig/aux-cache

Re: feedback doas / sudo / xfce-extras

[Heiko Zimmermann]

I forwarded to landry@

Thank you.

Heiko

Am 21.08.2015 um 16:16 schrieb Stuart Henderson:
 On 2015-08-21, Heiko Zimmermann open...@heiko-zimmermann.com wrote:
 Hello Tedu,

 I'm using xfce. I tried to pkg_delete sudo because of doas.
 doas is working fine for me.

 But I cant remove sudo because of dependencies. xfce-extras -
 xfce-mount - sudo.

 So I cant remove sudo without removing xfce-extras.

 Maybe - in future - there is a chance to integrate doas in xfce?

 Best Regards,
 Heiko
 
 xfce-mount doesn't really use sudo any more, you can specify to
 use it but that's done as user configuration. It looks like this
 dependency can just be removed (and DESCR adjusted so mention
 doas as well).

feedback doas / sudo / xfce-extras

[Heiko Zimmermann]

Hello Tedu,

I'm using xfce. I tried to pkg_delete sudo because of doas.
doas is working fine for me.

But I cant remove sudo because of dependencies. xfce-extras -
xfce-mount - sudo.

So I cant remove sudo without removing xfce-extras.

Maybe - in future - there is a chance to integrate doas in xfce?

Best Regards,
Heiko

Re: feedback doas / sudo / xfce-extras

[Stuart Henderson]

On 2015-08-21, Heiko Zimmermann open...@heiko-zimmermann.com wrote:
 Hello Tedu,

 I'm using xfce. I tried to pkg_delete sudo because of doas.
 doas is working fine for me.

 But I cant remove sudo because of dependencies. xfce-extras -
 xfce-mount - sudo.

 So I cant remove sudo without removing xfce-extras.

 Maybe - in future - there is a chance to integrate doas in xfce?

 Best Regards,
 Heiko

xfce-mount doesn't really use sudo any more, you can specify to
use it but that's done as user configuration. It looks like this
dependency can just be removed (and DESCR adjusted so mention
doas as well).

Re: no more sudo on openbsd 5.8

[John Naggets]

Thanks to all for your feedback. I will definitely go for the option
of distributing my own site58.tgz with doas.conf. Sounds great!

On Fri, Aug 7, 2015 at 10:23 PM, Stuart Henderson s...@spacehopper.org wrote:
 On 2015-08-07, John Naggets hostingnugg...@gmail.com wrote:
 Hello,

 I just installed OpenBSD snapshot (5.8) through an automated install
 and was surprise to login with my normal user and to find out that
 there is no sudo command available. Is this normal?

 I have setup the autoinstall for no root password and only one user
 account so I was wondering how do I run something as root now? Do I
 really need to setup a root account from autoinstall?

 You'll need to change procedure. Here are a few alternatives:

 - setup a root password,

 - setup a root ssh key and permit root logins (e.g. Allow root ssh =
 prohibit-password),

 - provide a site58.tgz with a doas.conf(5) file that permits access
 for members of wheel.

Re: no more sudo on openbsd 5.8

[Stuart Henderson]

On 2015-08-07, John Naggets hostingnugg...@gmail.com wrote:
 Hello,

 I just installed OpenBSD snapshot (5.8) through an automated install
 and was surprise to login with my normal user and to find out that
 there is no sudo command available. Is this normal?

 I have setup the autoinstall for no root password and only one user
 account so I was wondering how do I run something as root now? Do I
 really need to setup a root account from autoinstall?

You'll need to change procedure. Here are a few alternatives:

- setup a root password,

- setup a root ssh key and permit root logins (e.g. Allow root ssh =
prohibit-password),

- provide a site58.tgz with a doas.conf(5) file that permits access
for members of wheel.

no more sudo on openbsd 5.8

[John Naggets]

Hello,

I just installed OpenBSD snapshot (5.8) through an automated install
and was surprise to login with my normal user and to find out that
there is no sudo command available. Is this normal?

I have setup the autoinstall for no root password and only one user
account so I was wondering how do I run something as root now? Do I
really need to setup a root account from autoinstall?

Regards
John

Re: no more sudo on openbsd 5.8

[David Coppa]

On Fri, Aug 7, 2015 at 5:06 PM, John Naggets hostingnugg...@gmail.com wrote:
 Hello,

 I just installed OpenBSD snapshot (5.8) through an automated install
 and was surprise to login with my normal user and to find out that
 there is no sudo command available. Is this normal?

 I have setup the autoinstall for no root password and only one user
 account so I was wondering how do I run something as root now? Do I
 really need to setup a root account from autoinstall?

 Regards
 John


man doas

http://www.tedunangst.com/flak/post/doas


Ciao!
David
-- 
If you try a few times and give up, you'll never get there. But if
you keep at it... There's a lot of problems in the world which can
really be solved by applying two or three times the persistence that
other people will.
-- Stewart Nelson

Re: no more sudo on openbsd 5.8

[Todd C. Miller]

On Fri, 07 Aug 2015 17:06:03 +0200, John Naggets wrote:

 I just installed OpenBSD snapshot (5.8) through an automated install
 and was surprise to login with my normal user and to find out that
 there is no sudo command available. Is this normal?

Yes, sudo has moved to ports.  The new doas(1) acts like a simplified
sudo.

 I have setup the autoinstall for no root password and only one user
 account so I was wondering how do I run something as root now? Do I
 really need to setup a root account from autoinstall?

You can either use doas(1) or install the sudo port.

 - todd

Re: no more sudo on openbsd 5.8

[Maurice McCarthy]

On Fri, Aug 07, 2015 at 05:06:03PM +0200 or thereabouts, John Naggets wrote:
 Hello,
 
 I just installed OpenBSD snapshot (5.8) through an automated install
 and was surprise to login with my normal user and to find out that
 there is no sudo command available. Is this normal?
 
 I have setup the autoinstall for no root password and only one user
 account so I was wondering how do I run something as root now? Do I
 really need to setup a root account from autoinstall?
 
 Regards
 John
 

man doas

Re: passwd without argument in sudo

[Todd C. Miller]

On Wed, 15 Jul 2015 14:51:00 +0200, Alex Greif wrote:

 when I 'sudo su - ' into a root shell and issue a 'passwd' without a 
 username
 argument, then it does not try to change the passwd for the current user (in
 this case root) but for the user from which I issued the 'sudo'.

This is because passwd changes the password for the logged in user
by default, as returned by the logname system call.  You can run
the logname command to see that this is not changed when you run
su.

It's probably worth mentioning this in the passwd manual as it does
seem to cause some confusion.

 - todd

passwd without argument in sudo

[Alex Greif]

Hi,

with the current 5.8 snapshot I have a question on the following passwd(1)
behaviour:

when I 'sudo su - ' into a root shell and issue a 'passwd' without a 
username

argument, then it does not try to change the passwd for the current user (in
this case root) but for the user from which I issued the 'sudo'.

Unfortunately the man pages for passwd does not mention the case without
an argument, but on some other linux systems passwd without an argument
always changes the password of the current user.

I would appreciate if somebody could clarify this behaviour.

Here is a sample:

[agr...@foo.example.net] /home/agreif $ sudo su -

[r...@foo.example.net] /root # passwd
Changing local password for agreif.  why is this not for 
root?

New password:

[r...@foo.example.net] /root # echo $SHELL
/bin/ksh

[r...@foo.example.net] /root # uname -a
OpenBSD foo.example.net 5.8 GENERIC.MP#1139 amd64


thanks,
Alex.

Re: Have sudo and login changed between 5.6 and 5.7?

[Joel Rees]

On Tue, Jun 2, 2015 at 10:15 AM, Joel Rees joel.r...@gmail.com wrote:
 Checked in openbsd 5.6.

 2015/05/31 23:38 Joel Rees joel.r...@gmail.com:

 I have a home directory buried one deep in a directory owned by a
 non-login user:

 /home
 /home/bubble
 /home/bubble/userA

 where /home/bubble is owned by user/group bubble, with read and search
 permissions set for owner and group. userA is a member of the bubble
 group.

 Login says the home directory does not exist.

 When I make /home/bubble world readable, login finds the home directory.

 5.6 has the same behavior here, even without special login classes.

 Once logged in, when I try to

 sudo -H -u userB firefox

 it appears to try to start firefox, then give up. Nothing special in
 the logs, that I have noticed.

 Similar in 5.6, but more noise from firefox, so that I can see it is trying
 to start. No error message in /var/log or on stdout to explain why it gives
 up.

 userB is s a member of the userA group.

 So I have to correct this:

 sudo-ing firefox worked in 5.6. I'm not sure about the login stuff

 None of this worked as I decribe it here in openbsd 5.6. I think I'm going
 to assume that the firefox engineers must have recently decided that hiding
 user directories was a suspicious, malware-like activity.  Or something.

sudo -H -u userB -s cd; firefox

seems to work. I Haven't tried all the variations, but it looks like I
just needed to get the working directory set to userB's home
directory. Which makes sense. Guess I was forgetting how sudo works.

 dmesg below:
[...]

Sorry to use the list as a place to talk to myself.

-- 
Joel Rees

Re: Have sudo and login changed between 5.6 and 5.7?

[Joel Rees]

Checked in openbsd 5.6.

2015/05/31 23:38 Joel Rees joel.r...@gmail.com:

 I have a home directory buried one deep in a directory owned by a
 non-login user:

 /home
 /home/bubble
 /home/bubble/userA

 where /home/bubble is owned by user/group bubble, with read and search
 permissions set for owner and group. userA is a member of the bubble
 group.

 Login says the home directory does not exist.

 When I make /home/bubble world readable, login finds the home directory.

5.6 has the same behavior here, even without special login classes.

 Once logged in, when I try to

 sudo -H -u userB firefox

 it appears to try to start firefox, then give up. Nothing special in
 the logs, that I have noticed.

Similar in 5.6, but more noise from firefox, so that I can see it is trying
to start. No error message in /var/log or on stdout to explain why it gives
up.

 userB is s a member of the userA group.

So I have to correct this:

 sudo-ing firefox worked in 5.6. I'm not sure about the login stuff

None of this worked as I decribe it here in openbsd 5.6. I think I'm going
to assume that the firefox engineers must have recently decided that hiding
user directories was a suspicious, malware-like activity.  Or something.

 dmesg below:

 OpenBSD 5.7-stable (GENERIC.MP) #0: Thu May 28 06:12:04 JST 2015
 r...@phool.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 real mem = 1835790336 (1750MB)
 avail mem = 1783062528 (1700MB)
 mpath0 at root
 scsibus0 at mpath0: 256 targets
 mainbus0 at root
 bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xe4800 (43 entries)
 bios0: vendor Insyde version F.0A date 07/16/2014
 bios0: Hewlett-Packard HP Pavilion 10 Notebook PC
 acpi0 at bios0: rev 2
 acpi0: sleep states S0 S3 S4 S5
 acpi0: tables DSDT FACP UEFI HPET APIC MCFG ASF! BOOT FPDT MSDM SSDT
 SSDT SSDT SSDT SSDT
 acpi0: wakeup devices GPP0(S5) GPP1(S4) OHC1(S3) OHC2(S3) OHC3(S3)
 EHC1(S3) EHC2(S3) EHC3(S3) XHC0(S4) AWAD(S4)
 acpitimer0 at acpi0: 3579545 Hz, 32 bits
 acpihpet0 at acpi0: 14318180 Hz
 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
 cpu0 at mainbus0: apid 0 (boot processor)
 cpu0: AMD A4-1200 APU with Radeon(TM) HD Graphics, 998.27 MHz
 cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPC
NT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMC
R8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,ITSC,BMI1
 cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 1MB
 64b/line 16-way L2 cache
 cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully
associative
 cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully
associative
 cpu0: smt 0, core 0, package 0
 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
 cpu0: apic clock running at 99MHz
 cpu0: mwait min=64, max=64, C-substates=0.0.0.0.0, IBE
 cpu1 at mainbus0: apid 1 (application processor)
 cpu1: AMD A4-1200 APU with Radeon(TM) HD Graphics, 998.14 MHz
 cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPC
NT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMC
R8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,ITSC,BMI1
 cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 1MB
 64b/line 16-way L2 cache
 cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully
associative
 cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully
associative
 cpu1: smt 0, core 1, package 0
 ioapic0 at mainbus0: apid 0 pa 0xfec0, version 21, 24 pins
 ioapic1 at mainbus0: apid 5 pa 0xfec01000, version 21, 32 pins
 ioapic1: misconfigured as apic 0, remapped to apid 5
 acpimcfg0 at acpi0 addr 0xf800, bus 0-63
 acpiprt0 at acpi0: bus 0 (PCI0)
 acpiprt1 at acpi0: bus 1 (GPP0)
 acpiprt2 at acpi0: bus 5 (GPP1)
 acpiprt3 at acpi0: bus -1 (GPP2)
 acpiprt4 at acpi0: bus -1 (GPP3)
 acpiprt5 at acpi0: bus -1 (GFX_)
 acpiec0 at acpi0
 acpicpu0 at acpi0: PSS
 acpicpu1 at acpi0: PSS
 acpipwrres0 at acpi0: FN00, resource for FAN0
 acpitz0 at acpi0: critical temperature is 118 degC
 acpibtn0 at acpi0: PWRB
 acpiac0 at acpi0: AC unit online
 acpibat0 at acpi0: BAT0 model Primary serial 43346 03/09/2014 type
 LIon oem Hewlett-Packard
 acpibtn1 at acpi0: LID_
 acpivideo0 at acpi0: VGA_
 acpivideo1 at acpi0: VGA_
 cpu0: 998 MHz: speeds: 1000 900 800 700 600 MHz
 pci0 at mainbus0 bus 0
 pchb0 at pci0 dev 0 function 0 AMD AMD64 16h Host rev 0x00
 vga1 at pci0 dev 1 function 0 vendor ATI, unknown product 0x9839 rev
0x00
 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
 wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
 azalia0 at pci0 dev 1 function 1 vendor ATI, unknown product 0x9840
 rev 0x00: msi
 azalia0: no supported codecs
 pchb1 at pci0 dev 2 function 0 vendor AMD, unknown product 0x1538 rev
0x00
 ppb0 at pci0 dev 2 function 2 AMD AMD64 16h PCIE rev 0x00: msi

Have sudo and login changed between 5.6 and 5.7?

[Joel Rees]

I have a home directory buried one deep in a directory owned by a
non-login user:

/home
/home/bubble
/home/bubble/userA

where /home/bubble is owned by user/group bubble, with read and search
permissions set for owner and group. userA is a member of the bubble
group.

Login says the home directory does not exist.

When I make /home/bubble world readable, login finds the home directory.

Once logged in, when I try to

sudo -H -u userB firefox

it appears to try to start firefox, then give up. Nothing special in
the logs, that I have noticed.

userB is s a member of the userA group.

sudo-ing firefox worked in 5.6. I'm not sure about the login stuff

dmesg below:

OpenBSD 5.7-stable (GENERIC.MP) #0: Thu May 28 06:12:04 JST 2015
r...@phool.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 1835790336 (1750MB)
avail mem = 1783062528 (1700MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xe4800 (43 entries)
bios0: vendor Insyde version F.0A date 07/16/2014
bios0: Hewlett-Packard HP Pavilion 10 Notebook PC
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP UEFI HPET APIC MCFG ASF! BOOT FPDT MSDM SSDT
SSDT SSDT SSDT SSDT
acpi0: wakeup devices GPP0(S5) GPP1(S4) OHC1(S3) OHC2(S3) OHC3(S3)
EHC1(S3) EHC2(S3) EHC3(S3) XHC0(S4) AWAD(S4)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihpet0 at acpi0: 14318180 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD A4-1200 APU with Radeon(TM) HD Graphics, 998.27 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,ITSC,BMI1
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 1MB
64b/line 16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.0.0.0.0, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD A4-1200 APU with Radeon(TM) HD Graphics, 998.14 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,ITSC,BMI1
cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 1MB
64b/line 16-way L2 cache
cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 21, 24 pins
ioapic1 at mainbus0: apid 5 pa 0xfec01000, version 21, 32 pins
ioapic1: misconfigured as apic 0, remapped to apid 5
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (GPP0)
acpiprt2 at acpi0: bus 5 (GPP1)
acpiprt3 at acpi0: bus -1 (GPP2)
acpiprt4 at acpi0: bus -1 (GPP3)
acpiprt5 at acpi0: bus -1 (GFX_)
acpiec0 at acpi0
acpicpu0 at acpi0: PSS
acpicpu1 at acpi0: PSS
acpipwrres0 at acpi0: FN00, resource for FAN0
acpitz0 at acpi0: critical temperature is 118 degC
acpibtn0 at acpi0: PWRB
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT0 model Primary serial 43346 03/09/2014 type
LIon oem Hewlett-Packard
acpibtn1 at acpi0: LID_
acpivideo0 at acpi0: VGA_
acpivideo1 at acpi0: VGA_
cpu0: 998 MHz: speeds: 1000 900 800 700 600 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 AMD AMD64 16h Host rev 0x00
vga1 at pci0 dev 1 function 0 vendor ATI, unknown product 0x9839 rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
azalia0 at pci0 dev 1 function 1 vendor ATI, unknown product 0x9840
rev 0x00: msi
azalia0: no supported codecs
pchb1 at pci0 dev 2 function 0 vendor AMD, unknown product 0x1538 rev 0x00
ppb0 at pci0 dev 2 function 2 AMD AMD64 16h PCIE rev 0x00: msi
pci1 at ppb0 bus 1
rtsx0 at pci1 dev 0 function 0 Realtek RTL8402 Card Reader rev 0x01: msi
sdmmc0 at rtsx0
re0 at pci1 dev 0 function 2 Realtek 8101E rev 0x06: RTL8402
(0x4400), msi, address 14:58:d0:06:96:26
rlphy0 at re0 phy 7: RTL8201E 10/100 PHY, rev. 2
ppb1 at pci0 dev 2 function 3 AMD AMD64 16h PCIE rev 0x00: msi
pci2 at ppb1 bus 5
Ralink RT3290 rev 0x00 at pci2 dev 0 function 0 not configured
Ralink Bluetooth rev 0x00 at pci2 dev 0 function 1 not configured
xhci0 at pci0 dev 16 function 0 vendor AMD, unknown product 0x7814
rev 0x01: msi
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 AMD xHCI root hub rev 3.00/1.00 addr 1
ahci0

Re: sudo nohup tcpdump at startup

[Hrvoje Popovski]

On 3.2.2015. 5:16, Ted Unangst wrote:
 fRANz wrote:
 On Thu, Jan 29, 2015 at 10:54 PM, Christopher Barry
 christopher.r.ba...@gmail.com wrote:

 what happens if you source /etc/rc.local instead?
 as in:
 [ -f /etc/rc.local ]  . /etc/rc.local

 Hi Christopher,
 I'm sorry, same behaviour: some commands were correctly invoked, for example:

 /sbin/ifconfig pflog0 up  /sbin/pflogd -f /dev/null

 but not tcpdump in this specific form:

 sudo nohup tcpdump -n -v -l -q -n -e -ttt -i pflog0 action block |
 logger -t pf -p local2.info 

 The complete file is:

 # cat /etc/rc.local
 /sbin/ifconfig pflog0 up  /sbin/pflogd -f /dev/null
 sudo nohup tcpdump -n -v -l -q -n -e -ttt -i pflog0 action block |
 logger -t pf -p local2.info 

 I already tried full paths but don't help.

 Again,
 it's not a problem hack the rc file but when possible I avoid it, as
 suggested many times in this list ;-)
 
 This is the kind of thing I usually put in a small script, and add to root's
 crontab. I don't think you need the nohup and sudo, that's probably just
 complicating things. e.g.
 
 #!/bin/sh
 tcpdump -n | logger 2 error.log 
 
 then
 @reboot /root/tcpdump.sh
 

Hi,

is there any problem to just put this in crontab?

@reboot /usr/sbin/tcpdump -lnqttti pflog0 2 error.log | /usr/bin/logger
-t pf -p local2.info 

Re: sudo nohup tcpdump at startup

[Hrvoje Popovski]

On 4.2.2015. 15:13, Todd C. Miller wrote:
 On Wed, 04 Feb 2015 15:06:41 +0100, Hrvoje Popovski wrote:
 
 is there any problem to just put this in crontab?

 @reboot /usr/sbin/tcpdump -lnqttti pflog0 2 error.log | /usr/bin/logger
 -t pf -p local2.info 
 
 You should not try to run the command in the background since cron
 runs commands asyncronously.  Otherwise that looks OK.
 
  - todd
 


thank you 

Re: sudo nohup tcpdump at startup

[Todd C. Miller]

On Wed, 04 Feb 2015 15:06:41 +0100, Hrvoje Popovski wrote:

 is there any problem to just put this in crontab?
 
 @reboot /usr/sbin/tcpdump -lnqttti pflog0 2 error.log | /usr/bin/logger
 -t pf -p local2.info 

You should not try to run the command in the background since cron
runs commands asyncronously.  Otherwise that looks OK.

 - todd

Re: sudo nohup tcpdump at startup

[Jérémie Courrèges-Anglas]

fRANz andrea.francesc...@gmail.com writes:

 On Thu, Jan 29, 2015 at 10:54 PM, Christopher Barry
 christopher.r.ba...@gmail.com wrote:

 what happens if you source /etc/rc.local instead?
 as in:
 [ -f /etc/rc.local ]  . /etc/rc.local

 Hi Christopher,
 I'm sorry, same behaviour: some commands were correctly invoked, for example:

 /sbin/ifconfig pflog0 up  /sbin/pflogd -f /dev/null

 but not tcpdump in this specific form:

 sudo nohup tcpdump -n -v -l -q -n -e -ttt -i pflog0 action block |
 logger -t pf -p local2.info 

 The complete file is:

 # cat /etc/rc.local
 /sbin/ifconfig pflog0 up  /sbin/pflogd -f /dev/null
 sudo nohup tcpdump -n -v -l -q -n -e -ttt -i pflog0 action block |
 logger -t pf -p local2.info 

Here nohup applies to tcpdump(1) only, not to logger(1).

- nohup logger -t pf -p local2.info 

 I already tried full paths but don't help.

 Again,
 it's not a problem hack the rc file but when possible I avoid it, as
 suggested many times in this list ;-)

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: sudo nohup tcpdump at startup

[Leclerc, Sebastien]

On 2015-02-03 04:16:04, Ted Unangst t...@tedunangst.com wrote:
 This is the kind of thing I usually put in a small script, and add to root's
 crontab. I don't think you need the nohup and sudo, that's probably just
 complicating things. e.g.

 #!/bin/sh
 tcpdump -n | logger 2 error.log 

 then
 @reboot /root/tcpdump.sh

Works for me!

Sebastien

Re: sudo nohup tcpdump at startup

[Craig Skinner]

On 2015-02-02 Mon 20:03 PM |, fRANz wrote:
 
 # cat /etc/rc.local
 /sbin/ifconfig pflog0 up  /sbin/pflogd -f /dev/null
 sudo nohup tcpdump -n -v -l -q -n -e -ttt -i pflog0 action block | logger -t 
 pf -p local2.info 
   ?

/etc/rc.local is run by root on boot.

Check the environment rc.local runs with
by putting in something *like* this:

#!/bin/sh
#
#   $Id$
#

tmp=$(mktemp)
print ${tmp}  ${tmp}
logname  ${tmp}
umask  ${tmp}
pwd  ${tmp}
printenv | sort  ${tmp}
cat ${tmp} | mail -s 'rc.local env' root

ifconfig pflog0 up  pflogd -f /dev/null
tcpdump -n -v -l -q -n -e -ttt -i pflog0 action block | logger -t pf -p 
local2.info 





Cheers,
-- 
Craig Skinner.
Another superb Scottish country dance by Edinburgh University:
https://twitter.com/Craig_Skinner/status/562546356926308353
http://NewScotland.Org.UK/
GUSCDC (Glasgow Uni) ball in 3 weeks time!

Re: sudo nohup tcpdump at startup

[Ted Unangst]

fRANz wrote:
 On Thu, Jan 29, 2015 at 10:54 PM, Christopher Barry
 christopher.r.ba...@gmail.com wrote:
 
  what happens if you source /etc/rc.local instead?
  as in:
  [ -f /etc/rc.local ]  . /etc/rc.local
 
 Hi Christopher,
 I'm sorry, same behaviour: some commands were correctly invoked, for example:
 
 /sbin/ifconfig pflog0 up  /sbin/pflogd -f /dev/null
 
 but not tcpdump in this specific form:
 
 sudo nohup tcpdump -n -v -l -q -n -e -ttt -i pflog0 action block |
 logger -t pf -p local2.info 
 
 The complete file is:
 
 # cat /etc/rc.local
 /sbin/ifconfig pflog0 up  /sbin/pflogd -f /dev/null
 sudo nohup tcpdump -n -v -l -q -n -e -ttt -i pflog0 action block |
 logger -t pf -p local2.info 
 
 I already tried full paths but don't help.
 
 Again,
 it's not a problem hack the rc file but when possible I avoid it, as
 suggested many times in this list ;-)

This is the kind of thing I usually put in a small script, and add to root's
crontab. I don't think you need the nohup and sudo, that's probably just
complicating things. e.g.

#!/bin/sh
tcpdump -n | logger 2 error.log 

then
@reboot /root/tcpdump.sh

Re: sudo nohup tcpdump at startup

[fRANz]

On Thu, Jan 29, 2015 at 10:54 PM, Christopher Barry
christopher.r.ba...@gmail.com wrote:

 what happens if you source /etc/rc.local instead?
 as in:
 [ -f /etc/rc.local ]  . /etc/rc.local

Hi Christopher,
I'm sorry, same behaviour: some commands were correctly invoked, for example:

/sbin/ifconfig pflog0 up  /sbin/pflogd -f /dev/null

but not tcpdump in this specific form:

sudo nohup tcpdump -n -v -l -q -n -e -ttt -i pflog0 action block |
logger -t pf -p local2.info 

The complete file is:

# cat /etc/rc.local
/sbin/ifconfig pflog0 up  /sbin/pflogd -f /dev/null
sudo nohup tcpdump -n -v -l -q -n -e -ttt -i pflog0 action block |
logger -t pf -p local2.info 

I already tried full paths but don't help.

Again,
it's not a problem hack the rc file but when possible I avoid it, as
suggested many times in this list ;-)
-f

Re: sudo nohup tcpdump at startup

[Giancarlo Razzolini]

On 02-02-2015 17:03, fRANz wrote:
 Again,
 it's not a problem hack the rc file but when possible I avoid it, as
 suggested many times in this list;-)
You could use tmux for this. You can start a detached session that in
turn run your command. You can latter attach to it and see what went
wrong. My suggestion is that you call tmux from /etc/rc.local using su
-c to make it run as another user and then give that user permission to
sudo to root for running the tcpdump command. This way you avoid needing
to ssh as root to the machine, and can also filter which commands the
user can run in /etc/sudoers.

Cheers,
Giancarlo Razzolini

[demime 1.01d removed an attachment of type application/pkcs7-signature which 
had a name of smime.p7s]

Re: sudo nohup tcpdump at startup

[fRANz]

On Mon, Feb 2, 2015 at 8:11 PM, Giancarlo Razzolini
grazzol...@gmail.com wrote:

 You could use tmux for this. You can start a detached session that in turn
 run your command. You can latter attach to it and see what went wrong. My
 suggestion is that you call tmux from /etc/rc.local using su -c to make it
 run as another user and then give that user permission to sudo to root for
 running the tcpdump command. This way you avoid needing to ssh as root to
 the machine, and can also filter which commands the user can run in
 /etc/sudoers.

Hello Giancarlo,
nice tip, I'll try!
-f

sudo nohup tcpdump at startup

[fRANz]

Hello guys,
I implemented this config:

http://home.nuug.no/~peter/pf/newest/log2syslog.html

in order to stream pf logs to a remote machine.
If I add the command:

sudo nohup tcpdump -n -v -l -q -n -e -ttt -i pflog0 action block |
logger -t pf -p local2.info 

to the /etc/rc.local file and reboot the box, it works for the boot
time but then tcpdump process disappear (I'm sure the file is
processed because previous commands are committed successfully), like
something kills the process.

Just for test I move the command from /etc/rc.local to /etc/rc:
tcpdump still works perfectly, also after boot time, for every reboot.

What are differences between rc.local and rc executions? Could you
please help me to understand?
It's not a problem for me remove the command from rc.local and put it
in rc file but I'm curious to find the reason.

On this platform (OpenBSD 5.6 amd64 on PcEngines APU) rc.local is
invoked like this:

[ -f /etc/rc.local ]  sh /etc/rc.local

Thank you for any tip.
-f

Re: sudo nohup tcpdump at startup

[Christopher Barry]

On Thu, 29 Jan 2015 20:56:50 +0100
fRANz andrea.francesc...@gmail.com wrote:

Hello guys,
I implemented this config:

http://home.nuug.no/~peter/pf/newest/log2syslog.html

in order to stream pf logs to a remote machine.
If I add the command:

sudo nohup tcpdump -n -v -l -q -n -e -ttt -i pflog0 action block |
logger -t pf -p local2.info 

to the /etc/rc.local file and reboot the box, it works for the boot
time but then tcpdump process disappear (I'm sure the file is
processed because previous commands are committed successfully), like
something kills the process.

Just for test I move the command from /etc/rc.local to /etc/rc:
tcpdump still works perfectly, also after boot time, for every reboot.

What are differences between rc.local and rc executions? Could you
please help me to understand?
It's not a problem for me remove the command from rc.local and put it
in rc file but I'm curious to find the reason.

On this platform (OpenBSD 5.6 amd64 on PcEngines APU) rc.local is
invoked like this:

[ -f /etc/rc.local ]  sh /etc/rc.local

Thank you for any tip.
-f



what happens if you source /etc/rc.local instead?
as in:
[ -f /etc/rc.local ]  . /etc/rc.local

Re: Fix xfe (Was: sudo bad practice or inconsistency?)

[Raimo Niskanen]

On Sat, Oct 18, 2014 at 07:29:59AM +0200, Alessandro DE LAURENZIS wrote:
 On Fri 17/10 17:39, Raimo Niskanen wrote:
  
  As I read the man page for su it is the target's login shell that is
  invoked, and it need not always be /bin/sh - it can be changed.
  
  Therefore I suspect that you want -s /bin/sh  between su  and root.
 
 I'm confused:
 
 just22@poseidon:[~] sudo su -s /bin/sh root -c date
 Sat Oct 18 07:21:40 CEST 2014
 
 just22@poseidon:[~] su -s /bin/sh root -c date
 su: only the superuser may specify a login shell
 
 (this is really weird).

That is not weird.  sudo changes user (to root by default) and then calls
su -s /bin/sh root -c date and root is allowed to specify a login shell.

But just22 is not allowed by su to specify a login shell.

 
 Moreover, using the following:
 
 #define SUCMD -fn 7x14 -geometry 60x4 -e su root -c 'nohup xfe /dev/null 
 21  sleep 1'
 
 xfe correctly opens the password's window, but the echo is active during
 typing... (the same doesn't happen when I use sudo).

I can only make wild guesses here, but it might be related to exactly how
xfe starts the new process that gets this $SUCMD string; if it allocates a
PTY or not, and sudo maybe fixes the situation when it is used...

But the su arguments -c 'nohup xfe /dev/null 21  sleep 1' are not
portable as they assume root's login shell is a Bourne style shell; just as
-c 'nohup xfe  /dev/null  sleep 1' assumes a Csh style shell (that line
may come from FreeBSD since they per default use Csh as root login shell)

Perhaps -c 'nohup xfe /dev/null  sleep 1' works well enough and is
portable enough...

 
 It's just me?
 
 
 -- 
 Alessandro DE LAURENZIS
 [mailto:just22@gmail.com]
 LinkedIn: http://it.linkedin.com/in/delaurenzis

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB

Re: sudo bad practice or inconsistency?

[Thorsten Glaser]

Alessandro DE LAURENZIS just22.adl at gmail.com writes:

(line-wrapped because of GMane)

 #define SUDOCMD -fn 7x14 -geometry 60x4 -e sudo su -c 'nohup \
 xfe  /dev/null  sleep 1'
  ^^

Note that this will not work on OpenBSD anyway; even mksh, which
does implement this bashism, will not parse this as expected in
POSIX mode.

So, besides the changes the others already pointed out:

#define SUDOCMD -fn 7x14 -geometry 60x4 -e sudo su root -c 'nohup \
xfe /dev/null 21  sleep 1'

bye,
//mirabilos

Fix xfe (Was: sudo bad practice or inconsistency?)

[David Coppa]

 From: Thorsten Glaser t...@mirbsd.org
 Date: Fri, Oct 17, 2014 at 10:44 AM
 Subject: Re: sudo bad practice or inconsistency?
 To: misc@openbsd.org
 
 
 Alessandro DE LAURENZIS just22.adl at gmail.com writes:
 
 (line-wrapped because of GMane)
 
  #define SUDOCMD -fn 7x14 -geometry 60x4 -e sudo su -c 'nohup \
  xfe  /dev/null  sleep 1'
   ^^
 
 Note that this will not work on OpenBSD anyway; even mksh, which
 does implement this bashism, will not parse this as expected in
 POSIX mode.
 
 So, besides the changes the others already pointed out:
 
 #define SUDOCMD -fn 7x14 -geometry 60x4 -e sudo su root -c 'nohup \
 xfe /dev/null 21  sleep 1'


Brian et al., ok for the diff below?

Index: Makefile
===
RCS file: /cvs/ports/x11/xfe/Makefile,v
retrieving revision 1.33
diff -u -p -u -p -r1.33 Makefile
--- Makefile25 Nov 2013 18:39:02 -  1.33
+++ Makefile17 Oct 2014 11:45:34 -
@@ -3,7 +3,7 @@
 COMMENT=   MS-Explorer like file manager for X
 
 DISTNAME=  xfe-1.37
-REVISION=  0
+REVISION=  1
 CATEGORIES=x11
 
 HOMEPAGE=  http://roland65.free.fr/xfe/
Index: patches/patch-src_xfedefs_h
===
RCS file: patches/patch-src_xfedefs_h
diff -N patches/patch-src_xfedefs_h
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-src_xfedefs_h 17 Oct 2014 11:45:35 -
@@ -0,0 +1,20 @@
+$OpenBSD$
+
+Unbreak launching Xfe as root with sudo or su
+
+--- src/xfedefs.h.orig Fri Oct 17 13:41:26 2014
 src/xfedefs.h  Fri Oct 17 13:43:44 2014
+@@ -157,11 +157,11 @@
+ 
+ // Command to launch Xfe as root with sudo or su, using Xvt as a terminal
+ #ifndef SUDOCMD
+-#define SUDOCMD -fn 7x14 -geometry 60x4 -e sudo su -c 'nohup xfe  
/dev/null  sleep 1'
++#define SUDOCMD -fn 7x14 -geometry 60x4 -e sudo su root -c 'nohup xfe 
/dev/null 21  sleep 1'
+ #endif
+ 
+ #ifndef SUCMD
+-#define SUCMD -fn 7x14 -geometry 60x4 -e su -c 'nohup xfe  /dev/null  
sleep 1'
++#define SUCMD -fn 7x14 -geometry 60x4 -e su root -c 'nohup xfe /dev/null 
21  sleep 1'
+ #endif
+ 
+ // Tooltips setup time and duration

Re: Fix xfe (Was: sudo bad practice or inconsistency?)

[Raimo Niskanen]

On Fri, Oct 17, 2014 at 05:51:08AM -0600, David Coppa wrote:
  From: Thorsten Glaser t...@mirbsd.org
  Date: Fri, Oct 17, 2014 at 10:44 AM
  Subject: Re: sudo bad practice or inconsistency?
  To: misc@openbsd.org
  
  
  Alessandro DE LAURENZIS just22.adl at gmail.com writes:
  
  (line-wrapped because of GMane)
  
   #define SUDOCMD -fn 7x14 -geometry 60x4 -e sudo su -c 'nohup \
   xfe  /dev/null  sleep 1'
^^
  
  Note that this will not work on OpenBSD anyway; even mksh, which
  does implement this bashism, will not parse this as expected in
  POSIX mode.
  
  So, besides the changes the others already pointed out:
  
  #define SUDOCMD -fn 7x14 -geometry 60x4 -e sudo su root -c 'nohup \
  xfe /dev/null 21  sleep 1'

As I read the man page for su it is the target's login shell that is
invoked, and it need not always be /bin/sh - it can be changed.

Therefore I suspect that you want -s /bin/sh  between su  and root.

 
 
 Brian et al., ok for the diff below?
 
 Index: Makefile
 ===
 RCS file: /cvs/ports/x11/xfe/Makefile,v
 retrieving revision 1.33
 diff -u -p -u -p -r1.33 Makefile
 --- Makefile  25 Nov 2013 18:39:02 -  1.33
 +++ Makefile  17 Oct 2014 11:45:34 -
 @@ -3,7 +3,7 @@
  COMMENT= MS-Explorer like file manager for X
  
  DISTNAME=xfe-1.37
 -REVISION=0
 +REVISION=1
  CATEGORIES=  x11
  
  HOMEPAGE=http://roland65.free.fr/xfe/
 Index: patches/patch-src_xfedefs_h
 ===
 RCS file: patches/patch-src_xfedefs_h
 diff -N patches/patch-src_xfedefs_h
 --- /dev/null 1 Jan 1970 00:00:00 -
 +++ patches/patch-src_xfedefs_h   17 Oct 2014 11:45:35 -
 @@ -0,0 +1,20 @@
 +$OpenBSD$
 +
 +Unbreak launching Xfe as root with sudo or su
 +
 +--- src/xfedefs.h.orig   Fri Oct 17 13:41:26 2014
  src/xfedefs.hFri Oct 17 13:43:44 2014
 +@@ -157,11 +157,11 @@
 + 
 + // Command to launch Xfe as root with sudo or su, using Xvt as a terminal
 + #ifndef SUDOCMD
 +-#define SUDOCMD -fn 7x14 -geometry 60x4 -e sudo su -c 'nohup xfe  
 /dev/null  sleep 1'
 ++#define SUDOCMD -fn 7x14 -geometry 60x4 -e sudo su root -c 'nohup xfe 
 /dev/null 21  sleep 1'
 + #endif
 + 
 + #ifndef SUCMD
 +-#define SUCMD -fn 7x14 -geometry 60x4 -e su -c 'nohup xfe  /dev/null  
 sleep 1'
 ++#define SUCMD -fn 7x14 -geometry 60x4 -e su root -c 'nohup xfe /dev/null 
 21  sleep 1'
 + #endif
 + 
 + // Tooltips setup time and duration

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB

Re: Fix xfe (Was: sudo bad practice or inconsistency?)

[Alessandro DE LAURENZIS]

On Fri 17/10 17:39, Raimo Niskanen wrote:
 
 As I read the man page for su it is the target's login shell that is
 invoked, and it need not always be /bin/sh - it can be changed.
 
 Therefore I suspect that you want -s /bin/sh  between su  and root.

I'm confused:

just22@poseidon:[~] sudo su -s /bin/sh root -c date
Sat Oct 18 07:21:40 CEST 2014

just22@poseidon:[~] su -s /bin/sh root -c date
su: only the superuser may specify a login shell

(this is really weird).

Moreover, using the following:

#define SUCMD -fn 7x14 -geometry 60x4 -e su root -c 'nohup xfe /dev/null 21 
 sleep 1'

xfe correctly opens the password's window, but the echo is active during
typing... (the same doesn't happen when I use sudo).

It's just me?


-- 
Alessandro DE LAURENZIS
[mailto:just22@gmail.com]
LinkedIn: http://it.linkedin.com/in/delaurenzis

sudo bad practice or inconsistency?

[Alessandro DE LAURENZIS]

Dear list,

I was playing with xfe (which by the way I consider a great program) and
noticed that opening a root window with sudo in OBSD doesn't work.

After a bit of debugging, I found out that the root cause is the
following definition inside xfedefs.h:

#define SUDOCMD -fn 7x14 -geometry 60x4 -e sudo su -c 'nohup xfe  /dev/null 
 sleep 1'

Now, launching sudo that way returns an error:

just22@poseidon:[xfe] sudo su -c ls
su: no such login class: ls

so basically sudo is parsing the -c option instead of passing it to
su. Probably this is just a bad practice in sudo usage, nevertheless I
never encountered such a problem in the Linux world...

Now: which should be the right suggestion to make upstream? How the
command should be written (preferably preserving the su call, just to
minimize the impact on the code)?

From the sudo's man page:

--  The -- option indicates that sudo should stop processing
 command line arguments.

I tried something like this, without luck:

just22@poseidon:[xfe] sudo -- su -c ls
su: no such login class: ls

(but it's very likely I'm misinterpreting the option).

And, in any case, why the same command works in Linux? do they use a
modified/patched version?

Thanks in advance for your time

-- 
Alessandro DE LAURENZIS
[mailto:just22@gmail.com]
LinkedIn: http://it.linkedin.com/in/delaurenzis

Re: sudo bad practice or inconsistency?

[Todd C. Miller]

On Tue, 14 Oct 2014 20:58:56 +0200, Alessandro DE LAURENZIS wrote:

 Now, launching sudo that way returns an error:
 
 just22@poseidon:[xfe] sudo su -c ls
 su: no such login class: ls
 
 so basically sudo is parsing the -c option instead of passing it to
 su. Probably this is just a bad practice in sudo usage, nevertheless I
 never encountered such a problem in the Linux world...

No, su is parsing the -c option instead of passing it to the
shell.  It should be running:

su root -c ls

or:

su -- -c ls

This really has nothing to do with sudo.

 - todd

Re: sudo bad practice or inconsistency?

[Miod Vallat]

 just22@poseidon:[xfe] sudo su -c ls
 su: no such login class: ls
 
 so basically sudo is parsing the -c option instead of passing it to
 su.

No, it is not. If it were, the error message would come from sudo, not
from su.

 And, in any case, why the same command works in Linux? do they use a
 modified/patched version?

They use a different su(1). You might want to check the third example in
the OpenBSD manual page for su.

Re: sudo bad practice or inconsistency?

[Alessandro DE LAURENZIS]

On Tue 14/10 19:08, Miod Vallat wrote:
  just22@poseidon:[xfe] sudo su -c ls
  su: no such login class: ls
  
  so basically sudo is parsing the -c option instead of passing it to
  su.
 
 No, it is not. If it were, the error message would come from sudo, not
 from su.
 
  And, in any case, why the same command works in Linux? do they use a
  modified/patched version?
 
 They use a different su(1). You might want to check the third example in
 the OpenBSD manual page for su.

Todd, Miod,

My bad, two times (I misinterpreted the error message and I didn't read
the documentation, where the behavior is explicitly mentioned - into the
BUGS section of the su's man page, incidentally).

Thanks for your hints, that have pointed me in the right direction.

Cheers

-- 
Alessandro DE LAURENZIS
[mailto:just22@gmail.com]
LinkedIn: http://it.linkedin.com/in/delaurenzis

Re: sudo -u environment help

[Craig R. Skinner]

FYI;- The sudo users mailing list quickly said the 3 issues I identified
are known bugs, which have been fixed in newer sudo versions.

http://www.sudo.ws/sudo/stable.html
The current stable release of sudo is 1.8.10p3

$ sudo -V
Sudo version 1.7.2p8

$ uname -a
OpenBSD teak.britvault.co.uk 5.4 GENERIC#37 i386


http://thread.gmane.org/gmane.comp.tools.sudo.user/4367
http://thread.gmane.org/gmane.os.openbsd.misc/211823/

 
 Bug 387 refers to MAIL being fixed in 1.7.4:
 http://www.sudo.ws/bugs/show_bug.cgi?id=387
 
 Bug 527 (FreeBSD sudo -i doesn't use variables from /etc/login.conf)
 seems to be similar: http://www.sudo.ws/bugs/show_bug.cgi?id=527
 which is logged as Fixed in sudo 1.8.4
 
 Maybe that fix also covers the login.conf path  umask issues:
 
 http://www.sudo.ws/sudo/stable.html#1.8.4
 On systems that use login.conf, sudo -i now sets environment variables
 based on login.conf.
 
 
 http://www.sudo.ws/sudo/stable.html#1.8.5
 The initial evironment created when env_reset is in effect now includes
 the contents of /etc/environment on AIX systems and the setenv and
 path entries from /etc/login.conf on BSD systems.
 
 
 sudo-users mailing list sudo-us...@sudo.ws
 For list information, options, or to unsubscribe, visit:
 http://www.sudo.ws/mailman/listinfo/sudo-users

Re: sudo -u environment help

[Craig R. Skinner]

Would this be better asked on tech@?

On 2014-04-08 Tue 09:26 AM |, Craig R. Skinner wrote:
 To clarify, there are no ~/. shell dot files.
 
 $PATH  umask are set in /etc/login.conf
 $MAIL is the default set by login(1)
 
 /etc/profile sources /etc/ksh.kshrc, which just sets $PS1,
 window decor  some aliases, nothing major.
 
 This arrangement works fine when logging in directly,
 or via sudo su -l user
 
 From my reading of sudo(8), I thought the same environment could be
 gained with something like sudo -H -i -u username.
 
 Am I missing sudo flags or settings in /etc/sudoers?
 
 
 On 2014-04-04 Fri 11:30 AM |, Craig R. Skinner wrote:
  Hi,
  
  When sudo'ing to another user, how can I obtain all of their environment
  settings as they receive when logging in themselves?
  
  When I use sudo in this manner, settings such as $PATH, $MAIL  umask
  aren't being honoured:
  
  
  $ echo $LOGNAME; echo $PATH; echo $MAIL; umask
  craig
  /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/sbin:/usr/site/bin:/usr/site/sbin:/home/craig/bin
  /var/mail/craig
  027
  
  
  
  Here, $PATH, $MAIL  umask are unchanged:
  
  $ sudo -H -i -u david
  $ echo $LOGNAME; echo $PATH; echo $MAIL; umask
  david
  /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/sbin:/usr/site/bin:/usr/site/sbin:/home/craig/bin
  /var/mail/craig
  027
  
  
  Compare the difference when logging in as that user:
  
  $ login david
  ...
  $ echo $LOGNAME; echo $PATH; echo $MAIL; umask
  david
  /usr/bin:/bin:/usr/local/bin:/usr/site/bin:/home/david/bin
  /var/mail/david
  022
  
  
  
  
  /etc/login.conf:
  default:\
  :passwordcheck=/usr/local/bin/pwqcheck -1:\
  :passwordtries=0:\
  :path=/usr/bin /bin /usr/local/bin /usr/site/bin ~/bin:\
  :umask=022:\
  :datasize-cur=
  
  staff:\
  :path=/usr/bin /bin /usr/sbin /sbin /usr/local/bin /usr/local/sbin 
  /usr/site/bin /usr/site/sbin ~/bin:\
  :umask=027:\
  :datasize-cur=
  
  
  $ egrep 'env_|Defaults' /etc/sudoers | grep -v ^#
  Defaults env_keep +=DESTDIR DISTDIR EDITOR FETCH_CMD FLAVOR FTPMODE GROUP 
  MAKE
  Defaults env_keep +=MAKECONF MULTI_PACKAGES NOMAN OKAY_FILES OWNER 
  PKG_CACHE
  Defaults env_keep +=PKG_DBDIR PKG_DESTDIR PKG_PATH PKG_TMPDIR PORTSDIR
  Defaults env_keep +=RELEASEDIR SHARED_ONLY SSH_AUTH_SOCK SUBPACKAGE VISUAL
  Defaults env_keep +=WRKOBJDIR
  Defaults always_set_home, ignore_dot, use_loginclass
  
  
  
  login(1):
  
   login enters information into the environment (see environ(7)) 
  specifying
   the user's home directory (HOME), command interpreter (SHELL), search
   path (PATH), terminal type (TERM), and user name (both LOGNAME and 
  USER).
  
  ENVIRONMENT
   login sets the following environment variables:
  
   HOME
   MAIL
  
  sudo(8):
  
Command Environment
   ..  On BSD systems, if the use_loginclass option is
   enabled, the environment is initialized based on the path and setenv
   settings in /etc/login.conf.  The new environment contains the TERM,
   PATH, HOME, MAIL, SHELL, LOGNAME, USER, USERNAME and SUDO_* variables 
  in
   addition to variables from the invoking process permitted by the
   env_check and env_keep options.  This is effectively a whitelist for
   environment variables.
  
  
  
  How can I become another user - without knowing their password,
  and gain their 'natural' environment?
  
  e.g. from wheel group to a users group member.
  
  'su -l username'  'login username' require their password.
  
  I thought 'sudo -H -i -u username' would do it.
  
  Any suggestions on what else I need to configure?

Re: sudo -u environment help

[Craig R. Skinner]

To clarify, there are no ~/. shell dot files.

$PATH  umask are set in /etc/login.conf
$MAIL is the default set by login(1)

/etc/profile sources /etc/ksh.kshrc, which just sets $PS1,
window decor  some aliases, nothing major.

This arrangement works fine when logging in directly,
or via sudo su -l user

From my reading of sudo(8), I thought the same environment could be
gained with something like sudo -H -i -u username.

Am I missing sudo flags or settings in /etc/sudoers?


On 2014-04-04 Fri 11:30 AM |, Craig R. Skinner wrote:
 Hi,
 
 When sudo'ing to another user, how can I obtain all of their environment
 settings as they receive when logging in themselves?
 
 When I use sudo in this manner, settings such as $PATH, $MAIL  umask
 aren't being honoured:
 
 
 $ echo $LOGNAME; echo $PATH; echo $MAIL; umask
 craig
 /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/sbin:/usr/site/bin:/usr/site/sbin:/home/craig/bin
 /var/mail/craig
 027
 
 
 
 Here, $PATH, $MAIL  umask are unchanged:
 
 $ sudo -H -i -u david
 $ echo $LOGNAME; echo $PATH; echo $MAIL; umask
 david
 /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/sbin:/usr/site/bin:/usr/site/sbin:/home/craig/bin
 /var/mail/craig
 027
 
 
 Compare the difference when logging in as that user:
 
 $ login david
 ...
 $ echo $LOGNAME; echo $PATH; echo $MAIL; umask
 david
 /usr/bin:/bin:/usr/local/bin:/usr/site/bin:/home/david/bin
 /var/mail/david
 022
 
 
 
 
 /etc/login.conf:
 default:\
   :passwordcheck=/usr/local/bin/pwqcheck -1:\
   :passwordtries=0:\
   :path=/usr/bin /bin /usr/local/bin /usr/site/bin ~/bin:\
   :umask=022:\
   :datasize-cur=
 
 staff:\
   :path=/usr/bin /bin /usr/sbin /sbin /usr/local/bin /usr/local/sbin 
 /usr/site/bin /usr/site/sbin ~/bin:\
   :umask=027:\
   :datasize-cur=
 
 
 $ egrep 'env_|Defaults' /etc/sudoers | grep -v ^#
 Defaults env_keep +=DESTDIR DISTDIR EDITOR FETCH_CMD FLAVOR FTPMODE GROUP 
 MAKE
 Defaults env_keep +=MAKECONF MULTI_PACKAGES NOMAN OKAY_FILES OWNER PKG_CACHE
 Defaults env_keep +=PKG_DBDIR PKG_DESTDIR PKG_PATH PKG_TMPDIR PORTSDIR
 Defaults env_keep +=RELEASEDIR SHARED_ONLY SSH_AUTH_SOCK SUBPACKAGE VISUAL
 Defaults env_keep +=WRKOBJDIR
 Defaults always_set_home, ignore_dot, use_loginclass
 
 
 
 login(1):
 
  login enters information into the environment (see environ(7)) specifying
  the user's home directory (HOME), command interpreter (SHELL), search
  path (PATH), terminal type (TERM), and user name (both LOGNAME and USER).
 
 ENVIRONMENT
  login sets the following environment variables:
 
  HOME
  MAIL
 
 sudo(8):
 
   Command Environment
  ..  On BSD systems, if the use_loginclass option is
  enabled, the environment is initialized based on the path and setenv
  settings in /etc/login.conf.  The new environment contains the TERM,
  PATH, HOME, MAIL, SHELL, LOGNAME, USER, USERNAME and SUDO_* variables in
  addition to variables from the invoking process permitted by the
  env_check and env_keep options.  This is effectively a whitelist for
  environment variables.
 
 
 
 How can I become another user - without knowing their password,
 and gain their 'natural' environment?
 
 e.g. from wheel group to a users group member.
 
 'su -l username'  'login username' require their password.
 
 I thought 'sudo -H -i -u username' would do it.
 
 Any suggestions on what else I need to configure?

Re: sudo -u environment help

[Andres Perera]

On Fri, Apr 4, 2014 at 6:00 AM, Craig R. Skinner
skin...@britvault.co.uk wrote:
 Hi,

 When sudo'ing to another user, how can I obtain all of their environment
 settings as they receive when logging in themselves?

 When I use sudo in this manner, settings such as $PATH, $MAIL  umask
 aren't being honoured:

[...]

You do that with `sudo -c - -l`:

$ { ulimit -a; env; }  ea
$ sudo -c - -i 'ulimit -a; env'  eb
$ diff -u ea e
--- ea Tue Apr  8 07:13:11 2014
+++ eb Tue Apr  8 07:14:22 2014
@@ -1,29 +1,24 @@
 time(cpu-seconds)unlimited
 file(blocks) unlimited
 coredump(blocks) unlimited
-data(kbytes) 524288
-stack(kbytes)4096
+data(kbytes) 33554432
+stack(kbytes)8192
 lockedmem(kbytes)2667916
 memory(kbytes)   7984356
-nofiles(descriptors) 512
-processes128
+nofiles(descriptors) 128
+processes1310
 _=/usr/bin/env
+USERNAME=root
 XAUTHORITY=/home/a/.Xauthority
-LOGNAME=a
-WINDOWID=10485773
-WINDOWPATH=5
-XTERM_SHELL=/usr/bin/tmux
-HOME=/home/a
-PWD=/home/a
-XTERM_VERSION=XTerm/OpenBSD(301)
+LOGNAME=root
+HOME=/root
+SUDO_GID=1000
 DISPLAY=:0
+SUDO_COMMAND=/bin/ksh -c ulimit -a; env
+SUDO_USER=a
+SUDO_UID=1000
 MAIL=/var/mail/a
-PATH=/home/a/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin:/usr/games:.
-TMUX=/tmp/tmux-1000/default,3104,0
-PAGER=less
-TMUX_PANE=%2
-TERM=screen
+PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/local/bin
 SHELL=/bin/ksh
-DBUS_SESSION_BUS_ADDRESS=unix:path=/tmp/dbus-8X6HB7BfTU,guid=b24ea188864417630554661f5343d7bf
-USER=a
-XTERM_LOCALE=C
+TERM=screen
+USER=root

Also see `use_loginclass` in sudoers(5).

Re: sudo -u environment help

[Andres Perera]

On Tue, Apr 8, 2014 at 7:17 AM, Andres Perera andre...@zoho.com wrote:
 On Fri, Apr 4, 2014 at 6:00 AM, Craig R. Skinner
 skin...@britvault.co.uk wrote:
 Hi,

 When sudo'ing to another user, how can I obtain all of their environment
 settings as they receive when logging in themselves?

 When I use sudo in this manner, settings such as $PATH, $MAIL  umask
 aren't being honoured:

 [...]

 You do that with `sudo -c - -l`:

 $ { ulimit -a; env; }  ea
 $ sudo -c - -i 'ulimit -a; env'  eb
 $ diff -u ea e
 --- ea Tue Apr  8 07:13:11 2014
 +++ eb Tue Apr  8 07:14:22 2014
 @@ -1,29 +1,24 @@
  time(cpu-seconds)unlimited
  file(blocks) unlimited
  coredump(blocks) unlimited
 -data(kbytes) 524288
 -stack(kbytes)4096
 +data(kbytes) 33554432
 +stack(kbytes)8192
  lockedmem(kbytes)2667916
  memory(kbytes)   7984356
 -nofiles(descriptors) 512
 -processes128
 +nofiles(descriptors) 128
 +processes1310
  _=/usr/bin/env
 +USERNAME=root
  XAUTHORITY=/home/a/.Xauthority
 -LOGNAME=a
 -WINDOWID=10485773
 -WINDOWPATH=5
 -XTERM_SHELL=/usr/bin/tmux
 -HOME=/home/a
 -PWD=/home/a
 -XTERM_VERSION=XTerm/OpenBSD(301)
 +LOGNAME=root
 +HOME=/root
 +SUDO_GID=1000
  DISPLAY=:0
 +SUDO_COMMAND=/bin/ksh -c ulimit -a; env
 +SUDO_USER=a
 +SUDO_UID=1000
  MAIL=/var/mail/a

^ the fact that $MAIL is preserved is a bug according to sudo(8),
section ``Command Environment'':

  As a special case, if sudo's -i option (initial login) is specified, sudo
  will initialize the environment regardless of the value of env_reset.
  The DISPLAY, PATH and TERM variables remain unchanged; HOME, MAIL, SHELL,
  USER, and LOGNAME are set based on the target user.

As shown, $MAIL doesn't correspond to the target user, which in this
invocation would be root.

 -PATH=/home/a/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin:/usr/games:.
 -TMUX=/tmp/tmux-1000/default,3104,0
 -PAGER=less
 -TMUX_PANE=%2
 -TERM=screen
 +PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/local/bin
  SHELL=/bin/ksh
 -DBUS_SESSION_BUS_ADDRESS=unix:path=/tmp/dbus-8X6HB7BfTU,guid=b24ea188864417630554661f5343d7bf
 -USER=a
 -XTERM_LOCALE=C
 +TERM=screen
 +USER=root

 Also see `use_loginclass` in sudoers(5).

Re: sudo -u environment help

[Craig R. Skinner]

On 2014-04-08 Tue 07:17 AM |, Andres Perera wrote:
 
 You do that with `sudo -c - -l`:
 
 $ sudo -c - -i 'ulimit -a; env'  eb
 $ diff -u ea e
 --- ea Tue Apr  8 07:13:11 2014
 +++ eb Tue Apr  8 07:14:22 2014
 @@ -1,29 +1,24 @@
 -LOGNAME=a
 +LOGNAME=root
 
 Also see `use_loginclass` in sudoers(5).
 

Unfortunately Andres, that doesn't work here for non-root:

$ userinfo $LOGNAME | fgrep class
class   staff
^
$ echo $LOGNAME; echo $PATH; echo $MAIL; umask
craig
/usr/bin:/bin:/usr/sbin:.../usr/site/bin:/usr/site/sbin:/home/craig/bin
/var/mail/craig
027

$ userinfo david | fgrep class
class
$ sudo -c - -i -u david
$ userinfo $LOGNAME | fgrep class
class
^
$ echo $LOGNAME; echo $PATH; echo $MAIL; umask
david
/usr/bin:/bin:/usr/sbin:.../usr/site/bin:/usr/site/sbin:/home/craig/bin
  ^
/var/mail/craig
  ^
027
  ^

$ exit
$ fgrep use_loginclass /etc/sudoers
Defaults always_set_home, ignore_dot, use_loginclass

$ login david
Password:
$ echo $LOGNAME; echo $PATH; echo $MAIL; umask
david
/usr/bin:/bin:/usr/local/bin:/usr/site/bin:/home/david/bin
 ^
/var/mail/david
  ^
022
  ^
$ /usr/sbin/userinfo $LOGNAME | fgrep class
class
^




/etc/login.conf:
...
...
default:\
:path=/usr/bin /bin /usr/local/bin /usr/site/bin ~/bin:\
:umask=022:\
:datasize
 
staff:\
:path=/usr/bin /bin /usr/sbin /sbin /usr/local/bin /usr/local/sbin 
/usr/site/bin /usr/site/sbin ~/bin:\
:umask=027:\
:ignorenologin:\
:datasize...


$ sudo -c default -i -u david
sudo: only root can use -c default


From what I'm seeing, sudo -iu username isn't setting
$PATH, $MAIL  umask, as set by login/su -l, rather than shell dotfiles.

Re: sudo -u environment help

[Shawn K. Quinn]

On Fri, Apr 4, 2014, at 12:05 PM, David Coppa wrote:
 On Fri, Apr 4, 2014 at 7:01 PM, Todd norr...@gmail.com wrote:
  I think this should work
 
  sudo su - user
 
 Sure, it works.
 I often use it.
 

sudo -s user 

should work as well I think.

-- 
  Shawn K. Quinn
  skqu...@rushpost.com

Re: sudo -u environment help

[Craig R. Skinner]

On 2014-04-04 Fri 12:01 PM |, Todd wrote:
 I think this should work
 
 sudo su - user
 

Yes, going via root works.

How do I get the same user environment with something like:
sudo -H -i -u username

See below:

  
   When I use sudo in this manner, settings such as $PATH, $MAIL
umask aren't being honoured:
  
   $ sudo -H -i -u david
   $ echo $LOGNAME; echo $PATH; echo $MAIL; umask
   david
   /usr/bin:/bin:/usr/sbin:/s./bin:/usr/site/sbin:/home/craig/bin
   ^
   /var/mail/craig
^
   027
 not: 022
  
  
   sudo(8):
  
 Command Environment


By default, the env_reset option is enabled. .

...  On BSD systems, if the use_loginclass option is
enabled, the environment is initialized based on the path and setenv
settings in /etc/login.conf.  The new environment contains the TERM,
PATH, HOME, MAIL, SHELL, LOGNAME, USER, USERNAME and SUDO_* variables
  
   $ egrep 'env_|Defaults' /etc/sudoers | grep -v ^#
   .
   Defaults always_set_home, ignore_dot, use_loginclass
  

HOME, SHELL, LOGNAME, USER, USERNAME are being set.

PATH  MAIL are not.

I don't understand why sudo su -l username cleanly logs into the
user's environment, but sudo -i -u username ignores PATH, MAIL  umask

Is it necessary to go through root?

e.g: sudo vi /etc/pf.conf -vs- sudoedit /etc/pf.conf

sudo -u environment help

[Craig R. Skinner]

Hi,

When sudo'ing to another user, how can I obtain all of their environment
settings as they receive when logging in themselves?

When I use sudo in this manner, settings such as $PATH, $MAIL  umask
aren't being honoured:


$ echo $LOGNAME; echo $PATH; echo $MAIL; umask
craig
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/sbin:/usr/site/bin:/usr/site/sbin:/home/craig/bin
/var/mail/craig
027



Here, $PATH, $MAIL  umask are unchanged:

$ sudo -H -i -u david
$ echo $LOGNAME; echo $PATH; echo $MAIL; umask
david
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/sbin:/usr/site/bin:/usr/site/sbin:/home/craig/bin
/var/mail/craig
027


Compare the difference when logging in as that user:

$ login david
...
$ echo $LOGNAME; echo $PATH; echo $MAIL; umask
david
/usr/bin:/bin:/usr/local/bin:/usr/site/bin:/home/david/bin
/var/mail/david
022




/etc/login.conf:
default:\
:passwordcheck=/usr/local/bin/pwqcheck -1:\
:passwordtries=0:\
:path=/usr/bin /bin /usr/local/bin /usr/site/bin ~/bin:\
:umask=022:\
:datasize-cur=

staff:\
:path=/usr/bin /bin /usr/sbin /sbin /usr/local/bin /usr/local/sbin 
/usr/site/bin /usr/site/sbin ~/bin:\
:umask=027:\
:datasize-cur=


$ egrep 'env_|Defaults' /etc/sudoers | grep -v ^#
Defaults env_keep +=DESTDIR DISTDIR EDITOR FETCH_CMD FLAVOR FTPMODE GROUP MAKE
Defaults env_keep +=MAKECONF MULTI_PACKAGES NOMAN OKAY_FILES OWNER PKG_CACHE
Defaults env_keep +=PKG_DBDIR PKG_DESTDIR PKG_PATH PKG_TMPDIR PORTSDIR
Defaults env_keep +=RELEASEDIR SHARED_ONLY SSH_AUTH_SOCK SUBPACKAGE VISUAL
Defaults env_keep +=WRKOBJDIR
Defaults always_set_home, ignore_dot, use_loginclass



login(1):

 login enters information into the environment (see environ(7)) specifying
 the user's home directory (HOME), command interpreter (SHELL), search
 path (PATH), terminal type (TERM), and user name (both LOGNAME and USER).

ENVIRONMENT
 login sets the following environment variables:

 HOME
 MAIL

sudo(8):

  Command Environment
 ..  On BSD systems, if the use_loginclass option is
 enabled, the environment is initialized based on the path and setenv
 settings in /etc/login.conf.  The new environment contains the TERM,
 PATH, HOME, MAIL, SHELL, LOGNAME, USER, USERNAME and SUDO_* variables in
 addition to variables from the invoking process permitted by the
 env_check and env_keep options.  This is effectively a whitelist for
 environment variables.



How can I become another user - without knowing their password,
and gain their 'natural' environment?

e.g. from wheel group to a users group member.

'su -l username'  'login username' require their password.

I thought 'sudo -H -i -u username' would do it.

Any suggestions on what else I need to configure?

Re: sudo -u environment help

[Vijay Sankar]

Quoting Craig R. Skinner skin...@britvault.co.uk:


Hi,

When sudo'ing to another user, how can I obtain all of their environment
settings as they receive when logging in themselves?

When I use sudo in this manner, settings such as $PATH, $MAIL  umask
aren't being honoured:


$ echo $LOGNAME; echo $PATH; echo $MAIL; umask
craig
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/sbin:/usr/site/bin:/usr/site/sbin:/home/craig/bin
/var/mail/craig
027



Here, $PATH, $MAIL  umask are unchanged:

$ sudo -H -i -u david
$ echo $LOGNAME; echo $PATH; echo $MAIL; umask
david
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/sbin:/usr/site/bin:/usr/site/sbin:/home/craig/bin
/var/mail/craig
027


Compare the difference when logging in as that user:

$ login david
...
$ echo $LOGNAME; echo $PATH; echo $MAIL; umask
david
/usr/bin:/bin:/usr/local/bin:/usr/site/bin:/home/david/bin
/var/mail/david
022




/etc/login.conf:
default:\
:passwordcheck=/usr/local/bin/pwqcheck -1:\
:passwordtries=0:\
:path=/usr/bin /bin /usr/local/bin /usr/site/bin ~/bin:\
:umask=022:\
:datasize-cur=

staff:\
	:path=/usr/bin /bin /usr/sbin /sbin /usr/local/bin /usr/local/sbin  
/usr/site/bin /usr/site/sbin ~/bin:\

:umask=027:\
:datasize-cur=


$ egrep 'env_|Defaults' /etc/sudoers | grep -v ^#
Defaults env_keep +=DESTDIR DISTDIR EDITOR FETCH_CMD FLAVOR FTPMODE  
GROUP MAKE
Defaults env_keep +=MAKECONF MULTI_PACKAGES NOMAN OKAY_FILES OWNER  
PKG_CACHE

Defaults env_keep +=PKG_DBDIR PKG_DESTDIR PKG_PATH PKG_TMPDIR PORTSDIR
Defaults env_keep +=RELEASEDIR SHARED_ONLY SSH_AUTH_SOCK SUBPACKAGE VISUAL
Defaults env_keep +=WRKOBJDIR
Defaults always_set_home, ignore_dot, use_loginclass



login(1):

 login enters information into the environment (see environ(7))  
specifying

 the user's home directory (HOME), command interpreter (SHELL), search
 path (PATH), terminal type (TERM), and user name (both LOGNAME  
and USER).


ENVIRONMENT
 login sets the following environment variables:

 HOME
 MAIL

sudo(8):

  Command Environment
 ..  On BSD systems, if the use_loginclass option is
 enabled, the environment is initialized based on the path and setenv
 settings in /etc/login.conf.  The new environment contains the TERM,
 PATH, HOME, MAIL, SHELL, LOGNAME, USER, USERNAME and SUDO_* variables in
 addition to variables from the invoking process permitted by the
 env_check and env_keep options.  This is effectively a whitelist for
 environment variables.



How can I become another user - without knowing their password,
and gain their 'natural' environment?

e.g. from wheel group to a users group member.

'su -l username'  'login username' require their password.

I thought 'sudo -H -i -u username' would do it.

Any suggestions on what else I need to configure?




Instead of

'su -l username'  'login username'

as root, I just

su - username

That always works for me.

Vijay Sankar, M.Eng., P.Eng.
ForeTell Technologies Limited
vsan...@foretell.ca

-
This message was sent using ForeTell-POST 4.9

Re: sudo -u environment help

[Vadim Zhukov]

sudo -i ?
04.04.2014 14:31 пользователь Craig R. Skinner
skin...@britvault.co.uk
написал:

 Hi,

 When sudo'ing to another user, how can I obtain all of their environment
 settings as they receive when logging in themselves?

 When I use sudo in this manner, settings such as $PATH, $MAIL  umask
 aren't being honoured:


 $ echo $LOGNAME; echo $PATH; echo $MAIL; umask
 craig


/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/sbin:/usr/site/bin:/u
sr/site/sbin:/home/craig/bin
 /var/mail/craig
 027



 Here, $PATH, $MAIL  umask are unchanged:

 $ sudo -H -i -u david
 $ echo $LOGNAME; echo $PATH; echo $MAIL; umask
 david


/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/sbin:/usr/site/bin:/u
sr/site/sbin:/home/craig/bin
 /var/mail/craig
 027


 Compare the difference when logging in as that user:

 $ login david
 ...
 $ echo $LOGNAME; echo $PATH; echo $MAIL; umask
 david
 /usr/bin:/bin:/usr/local/bin:/usr/site/bin:/home/david/bin
 /var/mail/david
 022




 /etc/login.conf:
 default:\
 :passwordcheck=/usr/local/bin/pwqcheck -1:\
 :passwordtries=0:\
 :path=/usr/bin /bin /usr/local/bin /usr/site/bin ~/bin:\
 :umask=022:\
 :datasize-cur=

 staff:\
 :path=/usr/bin /bin /usr/sbin /sbin /usr/local/bin /usr/local/sbin
 /usr/site/bin /usr/site/sbin ~/bin:\
 :umask=027:\
 :datasize-cur=


 $ egrep 'env_|Defaults' /etc/sudoers | grep -v ^#
 Defaults env_keep +=DESTDIR DISTDIR EDITOR FETCH_CMD FLAVOR FTPMODE GROUP
 MAKE
 Defaults env_keep +=MAKECONF MULTI_PACKAGES NOMAN OKAY_FILES OWNER
 PKG_CACHE
 Defaults env_keep +=PKG_DBDIR PKG_DESTDIR PKG_PATH PKG_TMPDIR PORTSDIR
 Defaults env_keep +=RELEASEDIR SHARED_ONLY SSH_AUTH_SOCK SUBPACKAGE
 VISUAL
 Defaults env_keep +=WRKOBJDIR
 Defaults always_set_home, ignore_dot, use_loginclass



 login(1):

  login enters information into the environment (see environ(7))
 specifying
  the user's home directory (HOME), command interpreter (SHELL), search
  path (PATH), terminal type (TERM), and user name (both LOGNAME and
 USER).

 ENVIRONMENT
  login sets the following environment variables:

  HOME
  MAIL

 sudo(8):

   Command Environment
  ..  On BSD systems, if the use_loginclass option
 is
  enabled, the environment is initialized based on the path and setenv
  settings in /etc/login.conf.  The new environment contains the TERM,
  PATH, HOME, MAIL, SHELL, LOGNAME, USER, USERNAME and SUDO_* variables
 in
  addition to variables from the invoking process permitted by the
  env_check and env_keep options.  This is effectively a whitelist for
  environment variables.



 How can I become another user - without knowing their password,
 and gain their 'natural' environment?

 e.g. from wheel group to a users group member.

 'su -l username'  'login username' require their password.

 I thought 'sudo -H -i -u username' would do it.

 Any suggestions on what else I need to configure?

Re: sudo -u environment help

[Todd]

I think this should work

sudo su - user


On Fri, Apr 4, 2014 at 8:52 AM, Vadim Zhukov persg...@gmail.com wrote:

 sudo -i ?
 04.04.2014 14:31 ÐÏÌØÚÏ×ÁÔÅÌØ Craig R. Skinner
 skin...@britvault.co.uk
 ÎÁÐÉÓÁÌ:

  Hi,
 
  When sudo'ing to another user, how can I obtain all of their environment
  settings as they receive when logging in themselves?
 
  When I use sudo in this manner, settings such as $PATH, $MAIL  umask
  aren't being honoured:
 
 
  $ echo $LOGNAME; echo $PATH; echo $MAIL; umask
  craig
 
 


/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/sbin:/usr/site/bin:/u
 sr/site/sbin:/home/craig/bin
  /var/mail/craig
  027
 
 
 
  Here, $PATH, $MAIL  umask are unchanged:
 
  $ sudo -H -i -u david
  $ echo $LOGNAME; echo $PATH; echo $MAIL; umask
  david
 
 


/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/sbin:/usr/site/bin:/u
 sr/site/sbin:/home/craig/bin
  /var/mail/craig
  027
 
 
  Compare the difference when logging in as that user:
 
  $ login david
  ...
  $ echo $LOGNAME; echo $PATH; echo $MAIL; umask
  david
  /usr/bin:/bin:/usr/local/bin:/usr/site/bin:/home/david/bin
  /var/mail/david
  022
 
 
 
 
  /etc/login.conf:
  default:\
  :passwordcheck=/usr/local/bin/pwqcheck -1:\
  :passwordtries=0:\
  :path=/usr/bin /bin /usr/local/bin /usr/site/bin ~/bin:\
  :umask=022:\
  :datasize-cur=
 
  staff:\
  :path=/usr/bin /bin /usr/sbin /sbin /usr/local/bin
 /usr/local/sbin
  /usr/site/bin /usr/site/sbin ~/bin:\
  :umask=027:\
  :datasize-cur=
 
 
  $ egrep 'env_|Defaults' /etc/sudoers | grep -v ^#
  Defaults env_keep +=DESTDIR DISTDIR EDITOR FETCH_CMD FLAVOR FTPMODE
 GROUP
  MAKE
  Defaults env_keep +=MAKECONF MULTI_PACKAGES NOMAN OKAY_FILES OWNER
  PKG_CACHE
  Defaults env_keep +=PKG_DBDIR PKG_DESTDIR PKG_PATH PKG_TMPDIR PORTSDIR
  Defaults env_keep +=RELEASEDIR SHARED_ONLY SSH_AUTH_SOCK SUBPACKAGE
  VISUAL
  Defaults env_keep +=WRKOBJDIR
  Defaults always_set_home, ignore_dot, use_loginclass
 
 
 
  login(1):
 
   login enters information into the environment (see environ(7))
  specifying
   the user's home directory (HOME), command interpreter (SHELL),
 search
   path (PATH), terminal type (TERM), and user name (both LOGNAME and
  USER).
 
  ENVIRONMENT
   login sets the following environment variables:
 
   HOME
   MAIL
 
  sudo(8):
 
Command Environment
   ..  On BSD systems, if the use_loginclass option
  is
   enabled, the environment is initialized based on the path and setenv
   settings in /etc/login.conf.  The new environment contains the TERM,
   PATH, HOME, MAIL, SHELL, LOGNAME, USER, USERNAME and SUDO_*
 variables
  in
   addition to variables from the invoking process permitted by the
   env_check and env_keep options.  This is effectively a whitelist for
   environment variables.
 
 
 
  How can I become another user - without knowing their password,
  and gain their 'natural' environment?
 
  e.g. from wheel group to a users group member.
 
  'su -l username'  'login username' require their password.
 
  I thought 'sudo -H -i -u username' would do it.
 
  Any suggestions on what else I need to configure?

Re: sudo -u environment help

[David Coppa]

On Fri, Apr 4, 2014 at 7:01 PM, Todd norr...@gmail.com wrote:
 I think this should work

 sudo su - user

Sure, it works.
I often use it.

Re: Sudo no longer working with RADIUS logins after upgrade to 5.4

[Todd C. Miller]

On Thu, 07 Nov 2013 00:08:00 -0500, Ted Unangst wrote:

 Is this the correct behavior? As I understand it, when I run sudo, it
 asks for my password because it wants me to prove I'm me. I don't have
 to authenticate as the destination user, so why is the destination
 user's auth style being used?

No, which is why I suggested he backout the change in question.
OpenBSD-current has the missing parts of the change from sudo 1.7.9.

 - todd

Sudo no longer working with RADIUS logins after upgrade to 5.4

[Andrew Klettke]

We're seeing a strange issue where logging into a newly-upgraded 5.4 
machine with a RADIUS login works fine, but when trying to use sudo to 
execute commands, I get incorrect password attempts in 
/var/log/secure. Transcript of this (server name censored to foo, user 
censored to user), log messages, and dmesg follow, any help or insight 
would be very much appreciated. Sudo worked perfectly fine with this 
same user before the upgrade:


$ ssh foo
user@foo's password:
Last login: Wed Nov  6 11:04:55 2013 from .***.net
OpenBSD 5.4 (GENERIC.MP) #44: Tue Jul 30 12:13:32 MDT 2013

Welcome to OpenBSD: The proactively secure Unix-like operating system.

Please use the sendbug(1) utility to report bugs in the system.
Before reporting a bug, please try to reproduce it with the latest
version of the code.  With bug reports, please try to ensure that
enough information to reproduce the problem is enclosed, and if a
known fix for it exists, include that as well.

[foo:~]$ sudo whoami

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.

Password:
Where did you learn to type?
Password:
My pet ferret can type better than you!
Password:
Do you think like you type?
sudo: 3 incorrect password attempts
[foo:~]$



From /var/log/secure:
Nov  6 11:11:11 foo sudo: user : 3 incorrect password attempts ; 
TTY=ttyp1 ; PWD=/home/user ; USER=root ; COMMAND=/usr/bin/whoami


Dmesg:
OpenBSD 5.4 (GENERIC.MP) #44: Tue Jul 30 12:13:32 MDT 2013
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Atom(TM) CPU 330 @ 1.60GHz (GenuineIntel 686-class) 
1.61 GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF

real mem  = 2138222592 (2039MB)
avail mem = 2091827200 (1994MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 07/10/09, BIOS32 rev. 0 @ 0xf0010, 
SMBIOS rev. 2.5 @ 0xfd170 (27 entries)

bios0: vendor American Megatrends Inc. version 1.0a date 07/10/2009
bios0: Supermicro X7SLA
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG SLIC OEMB
acpi0: wakeup devices P0P2(S4) P0P1(S4) PS2K(S4) PS2M(S4) EUSB(S4) 
MC97(S4) P0P4(S4) P0P5(S4) P0P6(S4) P0P7(S4) P0P8(S4) LAN0(S1) P0P9(S4) 
LAN1(S1) USB0(S4) USB1(S4) [...]

acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 133MHz
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Atom(TM) CPU 330 @ 1.60GHz (GenuineIntel 686-class) 
1.61 GHz
cpu1: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF

cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Atom(TM) CPU 330 @ 1.60GHz (GenuineIntel 686-class) 
1.61 GHz
cpu2: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF

cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Atom(TM) CPU 330 @ 1.60GHz (GenuineIntel 686-class) 
1.61 GHz
cpu3: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF

ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 1, remapped to apid 4
acpimcfg0 at acpi0 addr 0xf000, bus 0-63
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P2)
acpiprt2 at acpi0: bus 4 (P0P1)
acpiprt3 at acpi0: bus 1 (P0P4)
acpiprt4 at acpi0: bus -1 (P0P5)
acpiprt5 at acpi0: bus -1 (P0P6)
acpiprt6 at acpi0: bus -1 (P0P7)
acpiprt7 at acpi0: bus 2 (P0P8)
acpiprt8 at acpi0: bus 3 (P0P9)
acpicpu0 at acpi0
acpicpu1 at acpi0
acpicpu2 at acpi0
acpicpu3 at acpi0
acpibtn0 at acpi0: SLPB
acpibtn1 at acpi0: PWRB
bios0: ROM list: 0xc/0xaa00!
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 Intel 82945G Host rev 0x02
vga1 at pci0 dev 2 function 0 Intel 82945G Video rev 0x02
intagp0 at vga1
agp0 at intagp0: aperture at 0xe000, size 0x1000
inteldrm0 at vga1
drm0 at inteldrm0
error: [drm:pid0:drm_edid_block_valid] *ERROR* EDID checksum is invalid, 
remainder is 130

Raw EDID:

00 ff ff ff ff ff ff 00  ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff  ff ff

Re: Sudo no longer working with RADIUS logins after upgrade to 5.4

[Andrew Klettke]

Should also add that a /usr/bin/sudo binary copied over from a 5.3 
machine works as expected.


Thanks,

Andrew Klettke
Systems Admin
Optic Fusion

On 11/06/2013 11:17 AM, Andrew Klettke wrote:
We're seeing a strange issue where logging into a newly-upgraded 5.4 
machine with a RADIUS login works fine, but when trying to use sudo to 
execute commands, I get incorrect password attempts in 
/var/log/secure. Transcript of this (server name censored to foo, 
user censored to user), log messages, and dmesg follow, any help or 
insight would be very much appreciated. Sudo worked perfectly fine 
with this same user before the upgrade:


$ ssh foo
user@foo's password:
Last login: Wed Nov  6 11:04:55 2013 from .***.net
OpenBSD 5.4 (GENERIC.MP) #44: Tue Jul 30 12:13:32 MDT 2013

Welcome to OpenBSD: The proactively secure Unix-like operating system.

Please use the sendbug(1) utility to report bugs in the system.
Before reporting a bug, please try to reproduce it with the latest
version of the code.  With bug reports, please try to ensure that
enough information to reproduce the problem is enclosed, and if a
known fix for it exists, include that as well.

[foo:~]$ sudo whoami

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.

Password:
Where did you learn to type?
Password:
My pet ferret can type better than you!
Password:
Do you think like you type?
sudo: 3 incorrect password attempts
[foo:~]$



From /var/log/secure:
Nov  6 11:11:11 foo sudo: user : 3 incorrect password attempts ; 
TTY=ttyp1 ; PWD=/home/user ; USER=root ; COMMAND=/usr/bin/whoami


Dmesg:
OpenBSD 5.4 (GENERIC.MP) #44: Tue Jul 30 12:13:32 MDT 2013
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Atom(TM) CPU 330 @ 1.60GHz (GenuineIntel 686-class) 
1.61 GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF

real mem  = 2138222592 (2039MB)
avail mem = 2091827200 (1994MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 07/10/09, BIOS32 rev. 0 @ 
0xf0010, SMBIOS rev. 2.5 @ 0xfd170 (27 entries)

bios0: vendor American Megatrends Inc. version 1.0a date 07/10/2009
bios0: Supermicro X7SLA
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG SLIC OEMB
acpi0: wakeup devices P0P2(S4) P0P1(S4) PS2K(S4) PS2M(S4) EUSB(S4) 
MC97(S4) P0P4(S4) P0P5(S4) P0P6(S4) P0P7(S4) P0P8(S4) LAN0(S1) 
P0P9(S4) LAN1(S1) USB0(S4) USB1(S4) [...]

acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 133MHz
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Atom(TM) CPU 330 @ 1.60GHz (GenuineIntel 686-class) 
1.61 GHz
cpu1: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF

cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Atom(TM) CPU 330 @ 1.60GHz (GenuineIntel 686-class) 
1.61 GHz
cpu2: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF

cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Atom(TM) CPU 330 @ 1.60GHz (GenuineIntel 686-class) 
1.61 GHz
cpu3: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF

ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 1, remapped to apid 4
acpimcfg0 at acpi0 addr 0xf000, bus 0-63
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P2)
acpiprt2 at acpi0: bus 4 (P0P1)
acpiprt3 at acpi0: bus 1 (P0P4)
acpiprt4 at acpi0: bus -1 (P0P5)
acpiprt5 at acpi0: bus -1 (P0P6)
acpiprt6 at acpi0: bus -1 (P0P7)
acpiprt7 at acpi0: bus 2 (P0P8)
acpiprt8 at acpi0: bus 3 (P0P9)
acpicpu0 at acpi0
acpicpu1 at acpi0
acpicpu2 at acpi0
acpicpu3 at acpi0
acpibtn0 at acpi0: SLPB
acpibtn1 at acpi0: PWRB
bios0: ROM list: 0xc/0xaa00!
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 Intel 82945G Host rev 0x02
vga1 at pci0 dev 2 function 0 Intel 82945G Video rev 0x02
intagp0 at vga1
agp0 at intagp0: aperture at 0xe000, size 0x1000
inteldrm0 at vga1
drm0 at inteldrm0
error: [drm:pid0:drm_edid_block_valid] *ERROR* EDID checksum is 
invalid, remainder is 130

Raw EDID:

00 ff ff ff ff ff ff 00  ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff  ff ff

Re: Sudo no longer working with RADIUS logins after upgrade to 5.4

[Andrew Klettke]

Hey man, hope you're doing well.

The new version of sudo definitely breaks radius support somehow.

Old binary on newly-upgraded server, calling login_radius as expected:

32409 sudo CALL  lstat(0xcfbda248,0xcfbd9fe0)
  32409 sudo NAMI  /usr/libexec/auth/login_radius
  32409 sudo STRU  struct stat { dev=1030, ino=1559049, 
mode=-r-xr-sr-x , nlink=1, uid=0, gid=63, rdev=6221688, 
atime=1383766914.276995603, mtime=1375206816, 
ctime=1383763312.710865788, size=14768, blocks=32, blksize=16384, 
flags=0x0, gen=0x79206db9 }
  32409 sudo RET   lstat 0
  32409 sudo CALL socketpair(PF_LOCAL,SOCK_STREAM,0,0xcfbda1cc)
  32409 sudo RET   socketpair 0
  32409 sudo CALL  fork()
  32409 sudo RET   fork 4137/0x1029
  32409 sudo CALL  close(0x5)
  32409 sudo RET   close 0
  32409 sudo CALL  sigprocmask(SIG_BLOCK,~0)
  32409 sudo RET   sigprocmask 0
  32409 sudo CALL mprotect(0x2cff2000,0x2000,0x3PROT_READ|PROT_WRITE)
  32409 sudo RET   mprotect 0
  32409 sudo CALL mprotect(0x2cff2000,0x2000,0x1PROT_READ)
  32409 sudo RET   mprotect 0
  32409 sudo CALL  sigprocmask(SIG_SETMASK,0)
  32409 sudo RET   sigprocmask ~0x10100SIGKILL|SIGSTOP
  32409 sudo CALL  write(0x3,0x89efdeac,0x1)
  32409 sudo GIO   fd 3 wrote 1 bytes
\0
  32409 sudo RET   write 1
  32409 sudo CALL  write(0x3,0x819f6a4c,0xa)
  32409 sudo GIO   fd 3 wrote 10 bytes
\0
  32409 sudo RET   write 10/0xa
  32409 sudo CALL  read(0x3,0x7ec6b034,0x2000)
  32409 sudo GIO   fd 3 read 10 bytes
authorize



New binary on newly-upgraded server, no longer calling login_radius:

31629 sudo CALL  lstat(0xcfbfc908,0xcfbfc6a0)
  31629 sudo NAMI  /usr/libexec/auth/login_passwd
  31629 sudo STRU  struct stat { dev=1030, ino=1559048, 
mode=-r-sr-xr-x , nlink=1, uid=0, gid=11, rdev=6233224, 
atime=1383766539.484583023, mtime=1375206816, 
ctime=1383763312.710865788, size=10256, blocks=24, blksize=16384, 
flags=0x0, gen=0xa0c01eca }
  31629 sudo RET   lstat 0
  31629 sudo CALL socketpair(PF_LOCAL,SOCK_STREAM,0,0xcfbfc88c)
  31629 sudo RET   socketpair 0
  31629 sudo CALL  fork()
  31629 sudo RET   fork 23258/0x5ada
  31629 sudo CALL  close(0x5)
  31629 sudo RET   close 0
  31629 sudo CALL  sigprocmask(SIG_BLOCK,~0)
  31629 sudo RET   sigprocmask 0
  31629 sudo CALL mprotect(0x2c105000,0x2000,0x3PROT_READ|PROT_WRITE)
  31629 sudo RET   mprotect 0
  31629 sudo CALL mprotect(0x2c105000,0x2000,0x1PROT_READ)
  31629 sudo RET   mprotect 0
  31629 sudo CALL  sigprocmask(SIG_SETMASK,0)
  31629 sudo RET   sigprocmask ~0x10100SIGKILL|SIGSTOP
  31629 sudo CALL  write(0x3,0x7e83d5bc,0x1)
  31629 sudo GIO   fd 3 wrote 1 bytes
\0
  31629 sudo RET   write 1
  31629 sudo CALL  write(0x3,0x8a96d20c,0xa)
  31629 sudo GIO   fd 3 wrote 10 bytes
***\0
  31629 sudo RET   write 10/0xa
  31629 sudo CALL  read(0x3,0x8a2d6034,0x2000)
  31629 sudo GIO   fd 3 read 7 bytes
reject


Thanks,

Andrew Klettke
Systems Admin
Optic Fusion

On 11/06/2013 11:28 AM, Bryan Irvine wrote:
 Now, that's interesting.  ktrace that sucker.


 On Wed, Nov 6, 2013 at 11:22 AM, Andrew Klettke 
 aklet...@opticfusion.net mailto:aklet...@opticfusion.net wrote:

 Should also add that a /usr/bin/sudo binary copied over from a 5.3
 machine works as expected.


 Thanks,

 Andrew Klettke
 Systems Admin
 Optic Fusion

 On 11/06/2013 11:17 AM, Andrew Klettke wrote:

 We're seeing a strange issue where logging into a
 newly-upgraded 5.4 machine with a RADIUS login works fine, but
 when trying to use sudo to execute commands, I get incorrect
 password attempts in /var/log/secure. Transcript of this
 (server name censored to foo, user censored to user), log
 messages, and dmesg follow, any help or insight would be very
 much appreciated. Sudo worked perfectly fine with this same
 user before the upgrade:

 $ ssh foo
 user@foo's password:
 Last login: Wed Nov  6 11:04:55 2013 from .***.net
 OpenBSD 5.4 (GENERIC.MP http://GENERIC.MP) #44: Tue Jul 30
 12:13:32 MDT 2013

 Welcome to OpenBSD: The proactively secure Unix-like operating
 system.

 Please use the sendbug(1) utility to report bugs in the system.
 Before reporting a bug, please try to reproduce it with the latest
 version of the code.  With bug reports, please try to ensure that
 enough information to reproduce the problem is enclosed, and if a
 known fix for it exists, include that as well.

 [foo:~]$ sudo whoami

 We trust you have received the usual lecture from the local System
 Administrator. It usually boils down to these three things:

 #1) Respect the privacy of others

Re: Sudo no longer working with RADIUS logins after upgrade to 5.4

[Todd C. Miller]

The only change I see to sudo between 5.3 and 5.4 that might be
related is this one.  You could try backing it out via patch -R
and see if the old behavior is restored.

 - todd

Index: sudo.c
===
RCS file: /home/cvs/openbsd/src/usr.bin/sudo/sudo.c,v
retrieving revision 1.43
diff -u -r1.43 sudo.c
--- sudo.c  8 Jul 2010 21:11:31 -   1.43
+++ sudo.c  6 Nov 2013 20:14:47 -
@@ -305,7 +305,7 @@
log_error(NO_STDERR|NO_EXIT, problem with defaults entries);
 
 /* Set login class if applicable. */
-set_loginclass(sudo_user.pw);
+set_loginclass(runas_pw ? runas_pw : sudo_user.pw);
 
 /* Update initial shell now that runas is set. */
 if (ISSET(sudo_mode, MODE_LOGIN_SHELL))

Re: Sudo no longer working with RADIUS logins after upgrade to 5.4

[Alexander Hall]

On 11/06/13 20:47, Andrew Klettke wrote:

Hey man, hope you're doing well.

The new version of sudo definitely breaks radius support somehow.

Old binary on newly-upgraded server, calling login_radius as expected:

32409 sudo CALL  lstat(0xcfbda248,0xcfbd9fe0)
   32409 sudo NAMI  /usr/libexec/auth/login_radius
   32409 sudo STRU  struct stat { dev=1030, ino=1559049,
mode=-r-xr-sr-x , nlink=1, uid=0, gid=63, rdev=6221688,
atime=1383766914.276995603, mtime=1375206816,
ctime=1383763312.710865788, size=14768, blocks=32, blksize=16384,
flags=0x0, gen=0x79206db9 }
   32409 sudo RET   lstat 0
   32409 sudo CALL socketpair(PF_LOCAL,SOCK_STREAM,0,0xcfbda1cc)
   32409 sudo RET   socketpair 0
   32409 sudo CALL  fork()
   32409 sudo RET   fork 4137/0x1029
   32409 sudo CALL  close(0x5)
   32409 sudo RET   close 0
   32409 sudo CALL  sigprocmask(SIG_BLOCK,~0)
   32409 sudo RET   sigprocmask 0
   32409 sudo CALL mprotect(0x2cff2000,0x2000,0x3PROT_READ|PROT_WRITE)
   32409 sudo RET   mprotect 0
   32409 sudo CALL mprotect(0x2cff2000,0x2000,0x1PROT_READ)
   32409 sudo RET   mprotect 0
   32409 sudo CALL  sigprocmask(SIG_SETMASK,0)
   32409 sudo RET   sigprocmask ~0x10100SIGKILL|SIGSTOP
   32409 sudo CALL  write(0x3,0x89efdeac,0x1)
   32409 sudo GIO   fd 3 wrote 1 bytes
 \0
   32409 sudo RET   write 1
   32409 sudo CALL  write(0x3,0x819f6a4c,0xa)
   32409 sudo GIO   fd 3 wrote 10 bytes
 \0
   32409 sudo RET   write 10/0xa
   32409 sudo CALL  read(0x3,0x7ec6b034,0x2000)
   32409 sudo GIO   fd 3 read 10 bytes
 authorize
 


New binary on newly-upgraded server, no longer calling login_radius:

31629 sudo CALL  lstat(0xcfbfc908,0xcfbfc6a0)
   31629 sudo NAMI  /usr/libexec/auth/login_passwd
   31629 sudo STRU  struct stat { dev=1030, ino=1559048,
mode=-r-sr-xr-x , nlink=1, uid=0, gid=11, rdev=6233224,
atime=1383766539.484583023, mtime=1375206816,
ctime=1383763312.710865788, size=10256, blocks=24, blksize=16384,
flags=0x0, gen=0xa0c01eca }
   31629 sudo RET   lstat 0
   31629 sudo CALL socketpair(PF_LOCAL,SOCK_STREAM,0,0xcfbfc88c)
   31629 sudo RET   socketpair 0
   31629 sudo CALL  fork()
   31629 sudo RET   fork 23258/0x5ada
   31629 sudo CALL  close(0x5)
   31629 sudo RET   close 0
   31629 sudo CALL  sigprocmask(SIG_BLOCK,~0)
   31629 sudo RET   sigprocmask 0
   31629 sudo CALL mprotect(0x2c105000,0x2000,0x3PROT_READ|PROT_WRITE)
   31629 sudo RET   mprotect 0
   31629 sudo CALL mprotect(0x2c105000,0x2000,0x1PROT_READ)
   31629 sudo RET   mprotect 0
   31629 sudo CALL  sigprocmask(SIG_SETMASK,0)
   31629 sudo RET   sigprocmask ~0x10100SIGKILL|SIGSTOP
   31629 sudo CALL  write(0x3,0x7e83d5bc,0x1)
   31629 sudo GIO   fd 3 wrote 1 bytes
 \0
   31629 sudo RET   write 1
   31629 sudo CALL  write(0x3,0x8a96d20c,0xa)
   31629 sudo GIO   fd 3 wrote 10 bytes
 ***\0
   31629 sudo RET   write 10/0xa
   31629 sudo CALL  read(0x3,0x8a2d6034,0x2000)
   31629 sudo GIO   fd 3 read 7 bytes
 reject
 


What happens if you specifically request radius authentication, e.g.

$ sudo -a radius whoami

?

/Alexander




Thanks,

Andrew Klettke
Systems Admin
Optic Fusion

On 11/06/2013 11:28 AM, Bryan Irvine wrote:

Now, that's interesting.  ktrace that sucker.


On Wed, Nov 6, 2013 at 11:22 AM, Andrew Klettke
aklet...@opticfusion.net mailto:aklet...@opticfusion.net wrote:

 Should also add that a /usr/bin/sudo binary copied over from a 5.3
 machine works as expected.


 Thanks,

 Andrew Klettke
 Systems Admin
 Optic Fusion

 On 11/06/2013 11:17 AM, Andrew Klettke wrote:

 We're seeing a strange issue where logging into a
 newly-upgraded 5.4 machine with a RADIUS login works fine, but
 when trying to use sudo to execute commands, I get incorrect
 password attempts in /var/log/secure. Transcript of this
 (server name censored to foo, user censored to user), log
 messages, and dmesg follow, any help or insight would be very
 much appreciated. Sudo worked perfectly fine with this same
 user before the upgrade:

 $ ssh foo
 user@foo's password:
 Last login: Wed Nov  6 11:04:55 2013 from .***.net
 OpenBSD 5.4 (GENERIC.MP http://GENERIC.MP) #44: Tue Jul 30
 12:13:32 MDT 2013

 Welcome to OpenBSD: The proactively secure Unix-like operating
 system.

 Please use the sendbug(1) utility to report bugs in the system.
 Before reporting a bug, please try to reproduce it with the latest
 version of the code.  With bug reports, please try to ensure that
 enough information to reproduce the problem is enclosed, and if a
 known fix for it exists, include that as well.

 [foo

Re: Sudo no longer working with RADIUS logins after upgrade to 5.4

[Andrew Klettke]

On 11/06/2013 12:26 PM, Alexander Hall wrote:

On 11/06/13 20:47, Andrew Klettke wrote:

Hey man, hope you're doing well.

The new version of sudo definitely breaks radius support somehow.

Old binary on newly-upgraded server, calling login_radius as expected:

32409 sudo CALL  lstat(0xcfbda248,0xcfbd9fe0)
   32409 sudo NAMI  /usr/libexec/auth/login_radius
   32409 sudo STRU  struct stat { dev=1030, ino=1559049,
mode=-r-xr-sr-x , nlink=1, uid=0, gid=63, rdev=6221688,
atime=1383766914.276995603, mtime=1375206816,
ctime=1383763312.710865788, size=14768, blocks=32, blksize=16384,
flags=0x0, gen=0x79206db9 }
   32409 sudo RET   lstat 0
   32409 sudo CALL socketpair(PF_LOCAL,SOCK_STREAM,0,0xcfbda1cc)
   32409 sudo RET   socketpair 0
   32409 sudo CALL  fork()
   32409 sudo RET   fork 4137/0x1029
   32409 sudo CALL  close(0x5)
   32409 sudo RET   close 0
   32409 sudo CALL  sigprocmask(SIG_BLOCK,~0)
   32409 sudo RET   sigprocmask 0
   32409 sudo CALL 
mprotect(0x2cff2000,0x2000,0x3PROT_READ|PROT_WRITE)

   32409 sudo RET   mprotect 0
   32409 sudo CALL mprotect(0x2cff2000,0x2000,0x1PROT_READ)
   32409 sudo RET   mprotect 0
   32409 sudo CALL  sigprocmask(SIG_SETMASK,0)
   32409 sudo RET   sigprocmask ~0x10100SIGKILL|SIGSTOP
   32409 sudo CALL  write(0x3,0x89efdeac,0x1)
   32409 sudo GIO   fd 3 wrote 1 bytes
 \0
   32409 sudo RET   write 1
   32409 sudo CALL  write(0x3,0x819f6a4c,0xa)
   32409 sudo GIO   fd 3 wrote 10 bytes
 \0
   32409 sudo RET   write 10/0xa
   32409 sudo CALL  read(0x3,0x7ec6b034,0x2000)
   32409 sudo GIO   fd 3 read 10 bytes
 authorize
 


New binary on newly-upgraded server, no longer calling login_radius:

31629 sudo CALL  lstat(0xcfbfc908,0xcfbfc6a0)
   31629 sudo NAMI  /usr/libexec/auth/login_passwd
   31629 sudo STRU  struct stat { dev=1030, ino=1559048,
mode=-r-sr-xr-x , nlink=1, uid=0, gid=11, rdev=6233224,
atime=1383766539.484583023, mtime=1375206816,
ctime=1383763312.710865788, size=10256, blocks=24, blksize=16384,
flags=0x0, gen=0xa0c01eca }
   31629 sudo RET   lstat 0
   31629 sudo CALL socketpair(PF_LOCAL,SOCK_STREAM,0,0xcfbfc88c)
   31629 sudo RET   socketpair 0
   31629 sudo CALL  fork()
   31629 sudo RET   fork 23258/0x5ada
   31629 sudo CALL  close(0x5)
   31629 sudo RET   close 0
   31629 sudo CALL  sigprocmask(SIG_BLOCK,~0)
   31629 sudo RET   sigprocmask 0
   31629 sudo CALL 
mprotect(0x2c105000,0x2000,0x3PROT_READ|PROT_WRITE)

   31629 sudo RET   mprotect 0
   31629 sudo CALL mprotect(0x2c105000,0x2000,0x1PROT_READ)
   31629 sudo RET   mprotect 0
   31629 sudo CALL  sigprocmask(SIG_SETMASK,0)
   31629 sudo RET   sigprocmask ~0x10100SIGKILL|SIGSTOP
   31629 sudo CALL  write(0x3,0x7e83d5bc,0x1)
   31629 sudo GIO   fd 3 wrote 1 bytes
 \0
   31629 sudo RET   write 1
   31629 sudo CALL  write(0x3,0x8a96d20c,0xa)
   31629 sudo GIO   fd 3 wrote 10 bytes
 ***\0
   31629 sudo RET   write 10/0xa
   31629 sudo CALL  read(0x3,0x8a2d6034,0x2000)
   31629 sudo GIO   fd 3 read 7 bytes
 reject
 


What happens if you specifically request radius authentication, e.g.

$ sudo -a radius whoami

?

/Alexander

Hi Alexander,

I get the following:

[foo:~]$ sudo -a radius whoami

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.

Password:
sudo: radius-server not configured
stty: unknown mode: doofus
Password:
sudo: 1 incorrect password attempt
[foo:~]$

Which is odd, and definitely incorrect, as it works with the old binary, 
and radius is set up correctly in login.conf (IP censored):


radius:\
:auth=radius:\
:radius-server=***.***.***.***:\
:ignorenologin:\
:requirehome@:\
:radius-challenge-styles=login:

Thanks,

Andrew Klettke
Systems Admin
Optic Fusion






Thanks,

Andrew Klettke
Systems Admin
Optic Fusion

On 11/06/2013 11:28 AM, Bryan Irvine wrote:

Now, that's interesting.  ktrace that sucker.


On Wed, Nov 6, 2013 at 11:22 AM, Andrew Klettke
aklet...@opticfusion.net mailto:aklet...@opticfusion.net wrote:

 Should also add that a /usr/bin/sudo binary copied over from a 5.3
 machine works as expected.


 Thanks,

 Andrew Klettke
 Systems Admin
 Optic Fusion

 On 11/06/2013 11:17 AM, Andrew Klettke wrote:

 We're seeing a strange issue where logging into a
 newly-upgraded 5.4 machine with a RADIUS login works fine, but
 when trying to use sudo to execute commands, I get incorrect
 password attempts in /var/log/secure. Transcript of this
 (server name censored to foo, user censored to user), log
 messages, and dmesg follow, any help

Re: Sudo no longer working with RADIUS logins after upgrade to 5.4

[Todd C. Miller]

On Wed, 06 Nov 2013 13:01:38 -0800, Andrew Klettke wrote:

 Which is odd, and definitely incorrect, as it works with the old binary, 
 and radius is set up correctly in login.conf (IP censored):
 
 radius:\
 :auth=radius:\
 :radius-server=***.***.***.***:\
 :ignorenologin:\
 :requirehome@:\
 :radius-challenge-styles=login:

This is almost certainly caused by revision 1.45 of sudo.c.  If you
back that out (see my previous messages) and rebuild sudo that
should fix it.

Basically, sudo is using the authentication style of the destination
user (in this case root) instead of the invoking user.  A workaround
may be to configure root to use radius authentication.

 - todd

Re: Sudo no longer working with RADIUS logins after upgrade to 5.4

[Ted Unangst]

On Wed, Nov 06, 2013 at 14:29, Todd C. Miller wrote:

 Basically, sudo is using the authentication style of the destination
 user (in this case root) instead of the invoking user.  A workaround
 may be to configure root to use radius authentication.

Is this the correct behavior? As I understand it, when I run sudo, it
asks for my password because it wants me to prove I'm me. I don't have
to authenticate as the destination user, so why is the destination
user's auth style being used?

Re: sudo configuration !ttytickets?

[Todd C. Miller]

On Fri, 13 Sep 2013 12:44:45 +0200, Donovan Watteau wrote:

 Am I right thinking that sudo in base is still vulnerable to
 CVE-2013-1776 for those who enable tty_tickets?

Yes, but the situation is no worse than with tty_tickets disabled.
If you are really worried about this you can simply disable the
time stamp files by setting timestamp_timeout to 0.  This makes
sudo a lot less convenient to use though.

 - todd

Re: sudo configuration !ttytickets?

[Alexander Hall]

On 09/12/13 02:59, Michael W. Lucas wrote:

Hi,

I've noticed that the sudo on OpenBSD seems to have !ttytickets set by
default. In other words, I authenticate sudo once on, say, ttyp4, and
all of my login sessions on all my other ttyp* have authenticated to
sudo.

This, well, kind of surprised me. I'm sure you folks have thought this
through in much more detail than I have, but I can't find anything on
the rationale behind it.

It seems insecure. Can anyone enlighten me as to the thinking here?

Thanks,
==ml




FWIW, I tend to append this to /etc/sudoers:

- - - -
# Local settings
Defaultspassprompt=Sudo password (%u@%h):, \
tty_tickets, \
passwd_timeout=0, \
timestamp_timeout=60

%wheel  ALL=(ALL:ALL) SETENV: ALL
- - - -

Meaning I do use the 'per-tty' sudo ticket, extending the timeout to 60 
minutes. Some issues remain though;


- Making sure to 'sudo -k' on leaving the shell (or, rather, tty).
  'trap' helps here, at least a bit, but I'm not sure I catch 100%
  of the cases.
- If you don't have a tty (ssh -T $HOST sudo $whatever), calling it
  again won't prompt for a password. (sudo -k $whatever would, however)

I'm sure there are more potential flaws with the setup. Call it security 
by obscurity if you please, but it makes me feel a tad better about 
upping the timeout.


The passprompt change is really helpful at times though, not to be 
mistaken for an ssh password, a sudo password on another machine or sth 
else.


/Alexander

Re: sudo configuration !ttytickets?

[Donovan Watteau]

On Thu, 12 Sep 2013 13:43:21 -0700, Todd C. Miller wrote:

 On Wed, 11 Sep 2013 20:59:08 -0400, Michael W. Lucas wrote:
 
  I've noticed that the sudo on OpenBSD seems to have !ttytickets set by
  default. In other words, I authenticate sudo once on, say, ttyp4, and
  all of my login sessions on all my other ttyp* have authenticated to
  sudo.
  
  This, well, kind of surprised me. I'm sure you folks have thought this
  through in much more detail than I have, but I can't find anything on
  the rationale behind it.
 
 
 It's quite simple really, the version of sudo in OpenBSD (a patched
 version of 1.7.2p8) predates the change use tty_tickets by default.
 
 I've always felt that tty_tickets gives a false sense of security,
 though it is somewhat improved in more recent sudo versions where
 the tty is determined via sysctl() rather than by ttyname().
 
  - todd

Hi,

Am I right thinking that sudo in base is still vulnerable to
CVE-2013-1776 for those who enable tty_tickets?

BTW, I was thinking about the following use case: PermitRootLogin set
to no, and a simple user who can only use public key SSH
authentication.  Defaults rootpw is set, too.  Then, I'd use sudo
when I'd need it (as it's suggested to use SUDO=/usr/bin/sudo for
ports, etc.).  Then, let's say someone manages to get the private key
of my user (that's already a big problem of course, but it's an
unprivileged user who can't sudo without providing root's password).
If the attacker logs in while the timestamp timeout is still valid he
can do whatever he wants with sudo without typing any password, right?
So I could set tty_tickets, but if it can't be trusted too much,
shouldn't su(1) be used instead for this use case? (or sudo with a 0
timestamp timeout, but then I'd rather use su.)

I hope this question isn't too stupid, but I'd rather ask.  Some parts
of the FAQ suggest setting up sudo, but with no particular setup, and
the one I was thinking about doesn't look good.

Thanks.

Re: sudo configuration !ttytickets?

[Nick Holland]

On 09/13/13 06:44, Donovan Watteau wrote:
 On Thu, 12 Sep 2013 13:43:21 -0700, Todd C. Miller wrote:
 
 On Wed, 11 Sep 2013 20:59:08 -0400, Michael W. Lucas wrote:
 
  I've noticed that the sudo on OpenBSD seems to have !ttytickets set by
  default. In other words, I authenticate sudo once on, say, ttyp4, and
  all of my login sessions on all my other ttyp* have authenticated to
  sudo.
  
  This, well, kind of surprised me. I'm sure you folks have thought this
  through in much more detail than I have, but I can't find anything on
  the rationale behind it.
 
 
 It's quite simple really, the version of sudo in OpenBSD (a patched
 version of 1.7.2p8) predates the change use tty_tickets by default.
 
 I've always felt that tty_tickets gives a false sense of security,
 though it is somewhat improved in more recent sudo versions where
 the tty is determined via sysctl() rather than by ttyname().
 
  - todd
 
 Hi,
 
 Am I right thinking that sudo in base is still vulnerable to
 CVE-2013-1776 for those who enable tty_tickets?
 
 BTW, I was thinking about the following use case: PermitRootLogin set
 to no, and a simple user who can only use public key SSH
 authentication.  Defaults rootpw is set, too.  Then, I'd use sudo
 when I'd need it (as it's suggested to use SUDO=/usr/bin/sudo for
 ports, etc.).  Then, let's say someone manages to get the private key
 of my user (that's already a big problem of course, but it's an
 unprivileged user who can't sudo without providing root's password).

non-root access to a machine is quite useful by itself, don't forget
that.  They may not be able to alter your machine, but it is still a
useful tool to an attacker.

 If the attacker logs in while the timestamp timeout is still valid he
 can do whatever he wants with sudo without typing any password, right?
 So I could set tty_tickets, but if it can't be trusted too much,
 shouldn't su(1) be used instead for this use case? (or sudo with a 0
 timestamp timeout, but then I'd rather use su.)
 
 I hope this question isn't too stupid, but I'd rather ask.  Some parts
 of the FAQ suggest setting up sudo, but with no particular setup, and
 the one I was thinking about doesn't look good.
 
 Thanks.

Your goal should probably be to be keeping inappropriate users out of
your system; making things clumsy after they are in is not really the
point, and could lead to poor administration.

There is a reason there are options -- there is no one right answer for
all uses.  Look at your realistic threats, and decide what measure of
risks and benefits you want.  su wins in simplicity, but does mandate a
shared password.  If you are the only admin, that's not an issue.

Nick.

Re: sudo configuration !ttytickets?

[Donovan Watteau]

On 09/13/13, Nick Holland wrote:
 On 09/13/13 06:44, Donovan Watteau wrote:
  Hi,
  
  Am I right thinking that sudo in base is still vulnerable to
  CVE-2013-1776 for those who enable tty_tickets?
  
  BTW, I was thinking about the following use case: PermitRootLogin set
  to no, and a simple user who can only use public key SSH
  authentication.  Defaults rootpw is set, too.  Then, I'd use sudo
  when I'd need it (as it's suggested to use SUDO=/usr/bin/sudo for
  ports, etc.).  Then, let's say someone manages to get the private key
  of my user (that's already a big problem of course, but it's an
  unprivileged user who can't sudo without providing root's password).
 
 non-root access to a machine is quite useful by itself, don't forget
 that.  They may not be able to alter your machine, but it is still a
 useful tool to an attacker.
 
  If the attacker logs in while the timestamp timeout is still valid he
  can do whatever he wants with sudo without typing any password, right?
  So I could set tty_tickets, but if it can't be trusted too much,
  shouldn't su(1) be used instead for this use case? (or sudo with a 0
  timestamp timeout, but then I'd rather use su.)
  
  I hope this question isn't too stupid, but I'd rather ask.  Some parts
  of the FAQ suggest setting up sudo, but with no particular setup, and
  the one I was thinking about doesn't look good.
  
  Thanks.
 
 Your goal should probably be to be keeping inappropriate users out of
 your system; making things clumsy after they are in is not really the
 point, and could lead to poor administration.

I was just trying to follow the mindset of not assuming that things
will not fail, and instead building things so that if there's any
problem it has less impact.  Of course, a stolen private key is probably
too much of an enormous fail in the first place.

 There is a reason there are options -- there is no one right answer for
 all uses.  Look at your realistic threats, and decide what measure of
 risks and benefits you want.  su wins in simplicity, but does mandate a
 shared password.  If you are the only admin, that's not an issue.

All right, so I think su better suits my use case.  Thank you very much.

Re: sudo configuration !ttytickets?

[Matthew Weigel]

On 2013-09-11 19:59, Michael W. Lucas wrote:


This, well, kind of surprised me. I'm sure you folks have thought this
through in much more detail than I have, but I can't find anything on
the rationale behind it.

It seems insecure. Can anyone enlighten me as to the thinking here?


I can't say whether this is the thinking of the OpenBSD developers, but 
I have seen some concerns over the years that tty_tickets gives a false 
sense of security.

--
Matthew Weigel
hacker
unique  idempot . ent

Re: sudo configuration !ttytickets?

[Ted Unangst]

On Thu, Sep 12, 2013 at 10:27, Matthew Weigel wrote:
 On 2013-09-11 19:59, Michael W. Lucas wrote:
 
 This, well, kind of surprised me. I'm sure you folks have thought this
 through in much more detail than I have, but I can't find anything on
 the rationale behind it.

 It seems insecure. Can anyone enlighten me as to the thinking here?
 
 I can't say whether this is the thinking of the OpenBSD developers, but
 I have seen some concerns over the years that tty_tickets gives a false
 sense of security.

This is technically true. If you used sudo on any tty (ttyA), somebody
at a different tty (ttyB) but logged in as the same uid, can simply
ptrace (gdb) the ttyA sh and tell it to run sudo.

This is a step more complicated than somebody just walking over to
your keyboard while you're getting coffee, but it's not particularly
difficult or implausible.

uid is the main means of implementing isolation in unix. Trying to
isolate two processes with the same uid is, imo, a generally fruitless
endeavor.

Re: sudo configuration !ttytickets?

[Michael W. Lucas]

On Wed, Sep 11, 2013 at 10:50:19PM -0600, Andy Bradford wrote:
 Thus said Michael W. Lucas on Wed, 11 Sep 2013 20:59:08 -0400:
 
  This, well, kind of surprised me. I'm sure you folks have thought this
  through in much more detail than I  have, but I can't find anything on
  the rationale behind it.
 
 Is sudo enabled for any non-root users by default?
 

Sudo isn't enabled for non-root users by default.

It just seems a really strange default choice, one that nobody else
shares. But I wouldn't be shocked if there's a really good reason for
the !ttytickets default.

==ml

-- 
Michael W. Lucas  -  mwlu...@michaelwlucas.com, Twitter @mwlauthor 
http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/
Absolute OpenBSD 2/e - http://www.nostarch.com/openbsd2e
coupon code ILUVMICHAEL gets you 30% off  helps me.

Re: sudo configuration !ttytickets?

[Todd C. Miller]

On Wed, 11 Sep 2013 20:59:08 -0400, Michael W. Lucas wrote:

 I've noticed that the sudo on OpenBSD seems to have !ttytickets set by
 default. In other words, I authenticate sudo once on, say, ttyp4, and
 all of my login sessions on all my other ttyp* have authenticated to
 sudo.
 
 This, well, kind of surprised me. I'm sure you folks have thought this
 through in much more detail than I have, but I can't find anything on
 the rationale behind it.

It's quite simple really, the version of sudo in OpenBSD (a patched
version of 1.7.2p8) predates the change use tty_tickets by default.

I've always felt that tty_tickets gives a false sense of security,
though it is somewhat improved in more recent sudo versions where
the tty is determined via sysctl() rather than by ttyname().

 - todd

Re: sudo configuration !ttytickets?

[Miod Vallat]

 I can't say whether this is the thinking of the OpenBSD developers,
 but I have seen some concerns over the years that tty_tickets gives
 a false sense of security.

Not to mention the annoyance.

Miod

sudo configuration !ttytickets?

[Michael W. Lucas]

Hi,

I've noticed that the sudo on OpenBSD seems to have !ttytickets set by
default. In other words, I authenticate sudo once on, say, ttyp4, and
all of my login sessions on all my other ttyp* have authenticated to
sudo.

This, well, kind of surprised me. I'm sure you folks have thought this
through in much more detail than I have, but I can't find anything on
the rationale behind it.

It seems insecure. Can anyone enlighten me as to the thinking here?

Thanks,
==ml

-- 
Michael W. Lucas  -  mwlu...@michaelwlucas.com, Twitter @mwlauthor 
http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/
Absolute OpenBSD 2/e - http://www.nostarch.com/openbsd2e
coupon code ILUVMICHAEL gets you 30% off  helps me.

Re: sudo configuration !ttytickets?

[Andy Bradford]

Thus said Michael W. Lucas on Wed, 11 Sep 2013 20:59:08 -0400:

 This, well, kind of surprised me. I'm sure you folks have thought this
 through in much more detail than I  have, but I can't find anything on
 the rationale behind it.

Is sudo enabled for any non-root users by default?

Andy
-- 
TAI64 timestamp: 40005231482b

Weird sudo behavior?

[Alvaro Mantilla Gimenez]

Hi,

  Today I found something weird on sudo behavior (at least I wasn't aware
of this). I logged in my server using ssh public key. Once I was in, I
executed 'sudo -i' to become root. My user has full sudo access using
password. Everything normal so far. Then I need it to open a new terminal
(on my local computer) and opened a new ssh connection to the server again.
This second time, using a different tty, I executed 'sudo -i' again and the
server let me become root without ask for my password. Is this normal? I
can imagine a scenario where an attacker got the public and private key of
some user (but not the password) and just connect to the server and execute
sudo in a time frame near to the user and get root access. Should sudo
check, also, the tty of the user when is asking for the password? I am
running OpenBSD 5.0 without any possibility to test that on 5.1 or current.
Could somebody test it? Is that the normal behavior of sudo?

   Thanks so much in advance and kind regards,

 Alvaro

Re: Weird sudo behavior?

[patrick keshishian]

$ man sudo

On Mon, Oct 8, 2012 at 4:19 PM, Alvaro Mantilla Gimenez
alv...@alvaromantilla.com wrote:
 Hi,

   Today I found something weird on sudo behavior (at least I wasn't aware
 of this). I logged in my server using ssh public key. Once I was in, I
 executed 'sudo -i' to become root. My user has full sudo access using
 password. Everything normal so far. Then I need it to open a new terminal
 (on my local computer) and opened a new ssh connection to the server again.
 This second time, using a different tty, I executed 'sudo -i' again and the
 server let me become root without ask for my password. Is this normal? I
 can imagine a scenario where an attacker got the public and private key of
 some user (but not the password) and just connect to the server and execute
 sudo in a time frame near to the user and get root access. Should sudo
 check, also, the tty of the user when is asking for the password? I am
 running OpenBSD 5.0 without any possibility to test that on 5.1 or current.
 Could somebody test it? Is that the normal behavior of sudo?

Thanks so much in advance and kind regards,

  Alvaro

Re: Weird sudo behavior?

[Alvaro Mantilla Gimenez]

?? What are you trying to point me send me to the man page? The Once a
user has been authenticated, a timestamp is updated and the user may then
use sudo without a password for a short period of time (5 minutes unless
overridden in sudoers). part? I was aware of this. This is the normal sudo
behavior. My point is if it is fine that sudo assumes that one user
connected on two different ttys should share the timestamp and execute sudo
commands without ask for a password because then my paranoid scenario is
possible.

   Regards,

   Alvaro

2012/10/8 patrick keshishian pkesh...@gmail.com

 $ man sudo

 On Mon, Oct 8, 2012 at 4:19 PM, Alvaro Mantilla Gimenez
 alv...@alvaromantilla.com wrote:
  Hi,
 
Today I found something weird on sudo behavior (at least I wasn't aware
  of this). I logged in my server using ssh public key. Once I was in, I
  executed 'sudo -i' to become root. My user has full sudo access using
  password. Everything normal so far. Then I need it to open a new terminal
  (on my local computer) and opened a new ssh connection to the server
 again.
  This second time, using a different tty, I executed 'sudo -i' again and
 the
  server let me become root without ask for my password. Is this normal? I
  can imagine a scenario where an attacker got the public and private key
 of
  some user (but not the password) and just connect to the server and
 execute
  sudo in a time frame near to the user and get root access. Should sudo
  check, also, the tty of the user when is asking for the password? I am
  running OpenBSD 5.0 without any possibility to test that on 5.1 or
 current.
  Could somebody test it? Is that the normal behavior of sudo?
 
 Thanks so much in advance and kind regards,
 
   Alvaro

Re: Weird sudo behavior?

[Todd C. Miller]

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

Re: Weird sudo behavior?

[Alvaro Mantilla Gimenez]

Thanks Todd!!

2012/10/8 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