On Fri, Jan 10, 2014 at 01:27:59PM +0800, Schaufler, Casey wrote: > > -----Original Message----- > > From: Yang, Chengwei > > Sent: Thursday, January 09, 2014 7:54 PM > > To: Yin, Kangkai > > Cc: Yang, Chengwei; Schaufler, Casey; [email protected] > > Subject: Re: [Dev] pam module for Smack > > > > On Fri, Jan 10, 2014 at 11:48:23AM +0800, Yin Kangkai wrote: > > > On 2014-01-10, 11:43 +0800, Yang Chengwei wrote: > > > > On Fri, Jan 10, 2014 at 10:15:28AM +0800, Yin Kangkai wrote: > > > > > On 2014-01-10, 09:52 +0800, Yin Kangkai wrote: > > > > > > On 2014-01-10, 09:46 +0800, Schaufler, Casey wrote: > > > > > > > > Yep, as long as the user session processes are spawned > > > > > > > > though [email protected], they've been set "User" label already. > > > > > > > > > > > > > > So if we started the sshd service with the User label that should > > > > > > > be > > fine, too. > > > > > > > > > > > > > > > > > > > Yes exactly. I can verify that. > > > > > > > > > > > > So the problem here I see has nothing to do with systemd. It's > > > > > > su and ssh (and sdbd) give you the shell, and they're not SMACK > > > > > > aware. That's my understanding. > > > > > > > > > > > > As Casey said, we might fix this by assigning User label to sdbd > > > > > > (which comes from system-server.service) and sshd.service, let > > > > > > me verify that. > > > > > > > > > > Verified, it works (for both sdbd and ssh) > > > > > > > > > > $ ssh [email protected] > > > > > Warning: Permanently added '192.168.129.3' (ECDSA) to the list of > > known hosts. > > > > > Password: > > > > > Welcome to Tizen > > > > > root:~> id > > > > > uid=0(root) gid=0(root) > > > > > groups=0(root),29(audio),6505(pulse-access),6506(pulse-rt) > > > > > context=User > > > > > > > > As I understand, if the user is root, its context should be "System"? > > > > > > > > > root:~> set_usb_debug.sh --sdb > > > > > root:~> Connection to 192.168.129.3 closed. > > > > > [x86_64] kai@kai-gentoo ~/Downloads $ ~/bin/sdb shell > > > > > sh-4.2$ id > > > > > uid=5100(developer) gid=5100(developer) > > groups=5100(developer),1004(input),6509(app_logging),6527(sys_logging) > > context=User > > > > > sh-4.2$ su > > > > > Password: > > > > > bash-4.2# id > > > > > uid=0(root) gid=0(root) > > > > > groups=0(root),29(audio),6505(pulse-access),6506(pulse-rt) > > > > > context=User > > > > > > > > And su should change user context too? Otherwise, it limit to "User" > > > > priviledges rather than "System". > > > > > > That depends on how you define a "User" domain, "root" is a user just > > > like any other users. > > > > I think root is always special and that's "System" domain design for it. > > No, a human is a user, no matter how super.
Yes, human is an user. However, is it the design we'll put *root* into "User" domain just like any other unpriviledged user? If so, there isn't a super user or all of them are super users in Tizen? -- Thanks, Chengwei > > > > > > > > > bash-4.2# > > > > > > > > > > Did not verify other side impact though (e.g. system_server being in > > User domain). > > > > > > > > Not understand, you're trying to start system_server in "User" domain? > > > > > > to make sdbd in "User" domain, i am changing the system-server.service... > > > > Oh, yes, however, system_server is a priviledged process, which has to do > > many priviledged operations, like data/time, clock, write process > > oom_score_adj in /proc and so on. > > > > I think these priviledged operations hasn't been (shouldn't) granted to > > "User" domain. > > > > -- > > Thanks, > > Chengwei
signature.asc
Description: Digital signature
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
