Re: hal privileges [was: Re: [Utopia] gnome-mount 0.3 is out]

[Artem Kachitchkine <Artem Kachitchkin Sun COM>]

> Maybe I just fail to see the point.. but all that HAL does in this
> respect is to provide privileged operations to users that are not
> usually privileged. I think we do this in a secure way (do you
> disagree?)

Well, you know what they say about ciphers: breach is rarely in 
alrogithm, it's most often in the implementation. People have written 
unix root daemons for years and have come to a conclusion that it's not 
a good idea unless there is no way around. Withing limits, of course, 
it's all about balance, you gain something, you lose something.

Writing root code requires more discipline, more peer review, more 
auditing, more testing... It's like walking around with a loaded gun: 
sure it's safe if you are a responsible person, but guess who's most 
paranoid about that - that's right, folks who actually used firearms a lot.

> I guess I'm asking.. why is it better to use that specific mount(2)
> Solaris syscall

It's the same mount(2) system call in Linux :)

> (the one that can be executed when euid!=0) than to just
> invoke Mount() on HAL? Is it because the hal-system-storage-mount (the
> helper for Mount() on HAL) would run with full privileges and thus
> invoke mount(1) with full privileges? If so, what are the specific
> problems and do you need something from HAL to fix this?

In addition to the above, users will have more choice with respect to 
automounters, they are not restricted to HAL. For instance, some control 
frea... uh, experienced users, don't like automatic mounters and prefer 
the standard /sbin/mount. Using mount privileges, Solaris doesn't need 
suid-root /sbin/mount commmand nor any special fstab options - it just 
works. Lowering the bar from HAL methods to the system call level makes 
the system simpler and more flexible at the same time.

> > I would like to take this opportunity and ask to keep Linux-specific 
> > assumptions to a minimum when thinking about HAL architecture. It will 
> > not only benefit other OSes, but also benefit Linux in the future, as it 
> > rapidly evolves.
>
> I hear your point, but in this specific case I fail to see what's so
> Linux specific about this.

I wasn't targetting this particular case, just slipped in a gentle 
reminder. Sometimes discussions revolve around specific examples, which 
kind of evolve into a prototype for a future solution. Things around 
here move pretty fast from the initial idea to implementation, which has 
it's pros and cons.

-Artem.