Playing with mdo(1)

Code: 
id -p
uid user
groups wheel operator video user
 mdo -i pkg update
Updating FreeBSD-ports repository catalogue...
FreeBSD-ports repository is up to date.
Updating FreeBSD-ports-kmods repository catalogue...
FreeBSD-ports-kmods repository is up to date.
All repositories are up to date.
id -p
uid    user
groups    wheel operator video user
 
fernandel said:
Code: 
id -p
Click to expand...
Thanks fernandel . I can't tell your primary group by the output of 'id -p'. With plain 'id', it looks like this:
$ id
uid=1001(ordinary) gid=1001(ordinary) groups=0(wheel),145(webcamd),1001(ordinary)

Edit: does 'mdo pkg update' work for you? (eg. without the '-i' switch)
 
Code: 
id
uid=1001(user) gid=1001(user) groups=0(wheel),5(operator),44(video),1001(user)
Code: 
 mdo pkg upgrade                                                                
mdo: setcred(): Operation not permitted
 
elephant my results (this was on the first page of the thread.)

For your earlier question.

mdo -i
root@scott2 scottro $ whoami
root
root@scott2 scottro $ id -p
login scottro
uid root
groups wheel video vboxusers scottro
 
fernandel that works but I have to specify '-i' everytime and -u no longer works.

If I take your rule and append gid=0,+gid=0,gid=5,+gid=5 then I no longer need '-i'.

Note that both clauses (gid=xxx and +gid=xxx) for wheel and operator need to be specified this way or it doesn't work.

I think this paragraph from the man page may be a clue:

The target process credentials have to be fully specified, either explicitly by listing all attributes and their requested values, or indirectly by establishing a baseline that provides a default value for each attribute, which can be amended by additional options.
Click to expand...

The rule I gave explicitly defines the target credentials while fernandel's example requires '-i' (implicit?) to infer the target credentials.
 
To add to an old thread. I had two machines where mdo -i worked as expected. However, on a third machine I'd get
cred() failed: Operation not permitted

It turned out that this was because on the 3rd machine, I wasn't a member of the wheel group. Once I added myself to wheel, logged out and logged back in, mdo worked as expected. I gave a thanks to elephant because his earlier post gave me the clue.
 
scottro said:
To add to an old thread. I had two machines where mdo -i worked as expected. However, on a third machine I'd get
cred() failed: Operation not permitted

It turned out that this was because on the 3rd machine, I wasn't a member of the wheel group. Once I added myself to wheel, logged out and logged back in, mdo worked as expected. I gave a thanks to elephant because his earlier post gave me the clue.
Click to expand...
Did you find something about logs, please?
 
Can we log mdo issued by auditd?
If we can log the setcred(2) issued with arguments, but I could not understand well how to do it.
 
Not really a problem, but I do not understand this behavior
Code: 
# sysctl security.mac.do.rules
security.mac.do.rules: uid=169>uid=0,gid=0;gid=0>any

# mdo -u acme mdo ls
mdo: setcred(): Operation not permitted
# mdo -u acme --euid root mdo ls
Makefile        distinfo        files           pkg-descr       pkg-plist
 
It turned out to be a simple problem
Setting the rule below and issuing mdo as the user acme(uid=169) does not work.

Code: 
$ sysctl security.mac.do.rules
security.mac.do.rules: uid=169>uid=0,gid=0

$ mdo  ls
mdo: setcred(): Operation not permitted
 
You must log in or register to reply here.
Back
Top