Bug 19946

Summary:

possible bug in sh(1) with -p flag (privileged mode)

Product:

Base System

Reporter:

alex <alex>

Component:

bin

Assignee:

alex <alex>

Status:

Closed FIXED

Severity:

Affects Only Me

Priority:

Normal

Version:

5.0-CURRENT

Hardware:

Any

OS:

Any

Attachments:

Description	Flags
file.diff	none

Description alex freebsd_committer

2000-07-15 10:00:02 UTC

I think I found a possible bug  in the sh(1) -p (privileged mode) behaviour.
On the one hand, the manpage is something broken (see pr 18243).

However, this is another thing.  If I understood the -p flag correctly
from the source and the current manpage, the -p flag should turn
off different real and effective user ids (and gids).
-p turns on, that the effective uid is set TO the real uid. (and the gid's
respectively).
However, in this case, it makes no sense, that STILL /etc/suid_profile
is parsed in spite of ~/.profile(!) - in fact, -p should turn OFF
the priviledged mode behaviour, or am I wrong?

So, I suggest to use the following patch, which sets the global variable
`privileged' to 0 again, after the -p flag is given and the
effective uid/gid are set to the real ones.
This makes sh parse ~/.profile later on (in main.c), which is
the correct behaviour in my opinion.

I'll take a look at the manpage later to clarify this.

Fix: cvs server: Diffing .
How-To-Repeat: 
n/a

Comment 1 Sheldon Hearn freebsd_committer

2000-07-17 18:47:31 UTC

Responsible Changed
From-To: freebsd-bugs->cracauer

Martin's our Bourne man.

Comment 2 Martin Cracauer freebsd_committer

2000-09-12 07:38:56 UTC

Responsible Changed
From-To: cracauer->freebsd-bugs

This PR is not really a shell bug, but a matter of security policy (sh 
has a switch -p that - when set - should allow root to su(8) to a user 
without inheriting anything from that user's dotfiles that would 
compromise root's account). 

Personally, I am not used to think of waterproofed security solutions 
and I see no reason how I should judge over the measurments such a 
flag must take to protect the user who su'ed.  Looking at bash2, it 
uses an entirely different (and apparently more though-off) approach 
towards the same problem.  I think this needs to be dicussed on 
-security. 

If anyone thinks of an appropriate solution (which includes your 
suggestion - Alexander), please have it reviewed by 
security@freebsd.org.  I will of course be happy to participiate in 
such a discussion where I can be of help and would commit and maintain 
a solution that is considered waterproofed by a substancial group of 
security-knowledgable people. 

I would also consider removing this switch as long as it's security 
gain is questionable. 
-:---F1  foo               (Text Fill)--L1--All---------------------------------

Comment 3 alex freebsd_committer

2001-03-10 17:57:13 UTC

Responsible Changed
From-To: freebsd-bugs->alex

Assign this PR to me as a reminder to start a discussion on -security 
about it, as Martin suggested (which will of course end in a bikeshed 
and result in a IPSEC cabable truncate(1)...).

Comment 4 alex freebsd_committer

2001-06-08 13:12:08 UTC

State Changed
From-To: open->closed

Further investigation tells me, that sh behaves correct.